Event-driven satellite service software service management system and method
By implementing an event-driven service management system, modular design and loosely coupled communication of satellite mission software were achieved, solving the problems of rigidity and poor scalability of traditional systems, improving system flexibility and fault recovery capabilities, and making it suitable for mission execution in complex aerospace environments.
Patent Information
- Application Number
- CN202511565232.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-30
- Publication Date
- 2026-03-03
AI Technical Summary
Traditional satellite mission software systems employ a tightly coupled design, resulting in system rigidity, poor scalability, limited fault handling capabilities, high development and maintenance costs, and a lack of autonomous recovery capabilities, which affects the stable operation and real-time response of satellites.
An event-driven service management system is adopted, which achieves modular and loosely coupled communication through the design of service layer, event framework layer and adaptation layer. It supports service registration, health monitoring and dynamic recovery, and improves system flexibility and maintainability by using publish-subscribe pattern and heartbeat detection mechanism.
It achieves functional decoupling, rapid expansion, and autonomous recovery of satellite mission software, reduces development and maintenance costs, improves system response speed and stability, and adapts to mission execution in complex aerospace environments.
Smart Images
Figure CN121597170A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software system technology, and in particular relates to an event-driven satellite service software management system and method. Background Technology
[0002] Satellite operational software is the core control system for satellite operation in orbit, responsible for key functions such as satellite platform management, mission scheduling, fault diagnosis, telemetry and remote control, power management, thermal control, and attitude and orbit control (AOCS). Its design must meet stringent requirements such as high reliability, real-time performance, low power consumption, and radiation resistance. For example... Figure 3 As shown, traditional satellite operational software systems typically employ a tightly coupled design, with sequential processing of interactions between functional modules relying on direct calls or fixed interfaces. This results in poor system scalability and maintainability. Furthermore, due to the lack of effective event management and monitoring mechanisms, a failure in one module often leads to the collapse or performance degradation of the entire system, severely impacting the satellite's stable operation and real-time response capabilities.
[0003] In summary, the existing technology has the following drawbacks: 1. The centralized architecture results in a rigid system with bloated code and high coupling. Code coupling is a metric in software engineering that measures the degree of interdependence between modules or components. Higher coupling indicates tighter connections and lower independence between modules. Traditional satellite management software is a monolithic design, with highly coupled, deeply bound, and overlapping code between its various functions (telemetry, remote control, and fault management). Modifying any module requires recompiling the entire system and performing full system regression testing, which can easily lead to aerospace quality issues and affect the normal operation of the satellite.
[0004] 2. Poor flexibility and difficult expansion; adding new payloads or functions requires code reconstruction, compatibility testing costs are high, and it is impossible to dynamically load them during satellite operation.
[0005] 3. Limited fault handling capabilities, long recovery cycle, and need for manual intervention; the limitation of ground station intervention required for software faults, lack of autonomous reasoning ability for software, inability to automatically recover in a short time, and sometimes delays of up to hours, requiring computer restart.
[0006] 4. High development and maintenance costs, repeated development required for different satellite platforms, low code reuse rate, and lack of universal design. Summary of the Invention
[0007] To address the shortcomings of existing technologies, this invention provides an event-driven satellite space service software management system and method.
[0008] Firstly, the system includes: a service layer, an event framework layer, and an adaptation layer; The service layer is used to generate or process events on different themes. It adopts a modular and service-oriented design and consists of a variable number of service modules, each of which contains one or more functional sub-modules. The service modules have service registration mechanisms, service association management, and service health monitoring functions. Each of the functional sub-modules follows the single responsibility principle and realizes data interaction through the event framework layer. The event framework layer consists of an event queue module and an event management module, which are used to build an internal data exchange mechanism for the system, specify that data flows in the form of events, and adopt a publish-subscribe pattern to achieve loosely coupled communication between various functional modules. The adaptation layer includes an operating system adaptation layer and a driver interface adaptation layer, which are used to shield the differences between the underlying hardware devices and the operating system, and provide a consistent operating environment and device access interface for the upper event framework layer and service layer. The operating system adaptation layer adopts the adapter design pattern to provide standardized interfaces for the event-driven layer and the service layer; the driver interface adaptation layer adopts hardware abstraction layer technology to uniformly encapsulate the driver interfaces of various hardware devices.
[0009] Furthermore, The service registration mechanism is used to dynamically manage the lifecycle of all services in the system and supports plug-and-play services. The service association management is used to maintain the mapping relationship between services and functional modules; The service health monitoring is based on the service health management function submodule. It monitors the service operation status through a multi-dimensional monitoring strategy of periodic heartbeat detection and response time statistics. When a service anomaly is detected, a service recovery process is triggered.
[0010] Furthermore, The service response process includes service restart, resource reclamation, and fault logging measures.
[0011] Secondly, the method, applied to the aforementioned event-driven satellite space service management system, includes: Initialize and prepare the service management system; Start the service management system; The service management system runs in cycles, monitors its running status, and detects and receives stop signals.
[0012] Furthermore, the initialization preparation of the service management system specifically includes, Perform driver initialization to complete the configuration and activation of the driver interface between the service management system and the hardware device; Perform event framework layer initialization, create an empty event queue, producer or consumer registry and routing table, complete the allocation of relevant memory space, and set the initial state of the event framework layer to the ready state. Perform service layer initialization, which initializes all services and their associated functional submodules.
[0013] Furthermore, starting the service management system specifically includes starting the event framework layer and starting the service layer.
[0014] Furthermore, the aforementioned startup event framework layer specifically includes, Start the event queue module and enter a continuous running state, continuously executing event dispatch operations; Start the event management module to listen for registration requests; these requests include new topic registration requests, new producer registration requests, new consumer registration requests, and consumer subscription requests. The startup service layer specifically includes: starting the service layer; performing service heartbeat monitoring; and handling anomalies.
[0015] Furthermore, the startup event management module listens for registration requests, specifically including, if a new topic registration request is detected, adding a corresponding event queue for the new topic and completing the initialization configuration of the queue; If a new producer registration request is detected, a unique identifier is assigned to the new producer, and its information is entered into the producer registry for management. If a new consumer registration request is detected, the topic that the consumer intends to associate with is verified. If the verification is successful, a unique identifier is assigned to the consumer and added to the consumer registry. If a consumer's request to subscribe to a topic is detected, the subscription topic is verified. If the verification is successful, the association between the consumer and the subscription topic is updated in the routing table for maintenance.
[0016] Furthermore, the startup service layer specifically includes a startup service layer, a parallel startup service module, and a startup service management function submodule, which is allocated a separate thread; The aforementioned service heartbeat monitoring and anomaly handling specifically includes, The service management function submodule initializes the heartbeat monitoring function and enters the monitoring loop state, checking the last active time of each service at certain intervals. The status is determined and processed based on the last active time of the service.
[0017] Furthermore, the status is determined and processed based on the last active time of the service, specifically including: If the last active time of the service is within the preset time from the current time, the service is considered to be running normally and monitoring will continue. If the last active time of a service is more than a preset time (e.g., 5 seconds) away from the current time, the service is determined to be abnormal. First, gracefully terminate the thread corresponding to the abnormal service, then re-initialize the abnormal service and try to restart it. If the restart is successful, the abnormal service will be brought back into the monitoring scope; if the restart fails, an alarm mechanism will be triggered, and the abnormal service will be isolated to avoid affecting the operation of other services.
[0018] Compared with the prior art, the present invention has the following advantages: 1. This invention decomposes satellite functions into independent modules (such as remote control, safety management, Ethernet communication, etc.) through a service layer, improves collaboration efficiency through standardized interfaces (modules interact through a unified interface), and allows modules with the same execution cycle to be freely combined into "services," achieving functional decoupling; and achieves unified encapsulation through an adaptation layer; thus hiding complexity and exposing simplicity, providing a unified operating system and driver standardization interface for upper-layer functional modules, significantly reducing the impact of changes to the operating system and hardware drivers; enabling rapid porting of satellite service software and reducing adaptation costs; and ensuring zero awareness of changes at the underlying level, eliminating cascading bugs.
[0019] 2. This invention proposes to use the cleanup function and follow the contract of "reversely and completely releasing private resources and releasing all held locks", which is uniformly called by the monitoring framework. This can not only prevent resource leakage, eliminate deadlock risk, and reduce management costs, but also ensure that the system can still run stably after multiple abnormal recovery.
[0020] 2. This invention utilizes the initialization phase to fully prepare the driver, event framework layer, and service layer, avoiding startup failures; during the startup and operation phase, the event framework layer continuously distributes events and accurately processes registration requests, while the service layer starts modules in parallel and monitors services through independent threads. The modules work together efficiently, improving the system response speed and meeting the real-time requirements of satellite on-orbit missions.
[0021] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings.
[0022] Attached image description [Yin Hu 1] 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 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 The diagram shows a schematic of the structure of a satellite service management system based on event-driven operation according to the present invention.
[0024] Figure 2 The diagram illustrates a process flow of an event-driven satellite service management method according to the present invention.
[0025] Figure 3 A schematic diagram of a traditional space service software architecture is shown.
[0026] Figure 4 A schematic diagram of the event distribution structure in an embodiment of the present invention is shown.
[0027] Figure 5 A schematic diagram of the event framework layer startup process in an embodiment of the present invention is shown.
[0028] Figure 6 A schematic diagram of the service layer startup process in an embodiment of the present invention is shown.
[0029] Figure 7 The static configuration table used in the embodiments of the present invention is shown. Detailed Implementation
[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.
[0031] To address the aforementioned shortcomings, this invention proposes an event-driven satellite mission software service management system. This system encapsulates multiple functional modules through a unified framework interface and employs an event-driven mechanism to achieve efficient communication and collaborative work between modules. It features automatic event distribution, thread safety, priority handling, component monitoring and automatic recovery, and dynamic subscription. It supports service status management, dynamic scheduling, dynamic topic addition, and dynamic service access, achieving scalability, functional decoupling, maintainability, and operational efficiency for the satellite mission software system. It is suitable for mission execution and resource management in complex aerospace environments.
[0032] like Figure 1 As shown, an event-driven satellite service management system includes: a service layer, an event framework layer, and an adaptation layer. 1. The service layer is used to generate or process events (i.e. data) on different themes. It adopts a modular and service-oriented design and consists of a variable number of service modules. Each service module is composed of one or more functional sub-modules. Each service module runs on an independent thread and its running cycle can be set.
[0033] Optionally, each functional submodule follows the single responsibility principle, responsible for completing its specific business function. For example, the telemetry data acquisition module is specifically responsible for collecting and packaging satellite status information, the remote control command processing module is specifically responsible for parsing and executing ground commands, and the energy management module is specifically responsible for scheduling and optimizing the satellite energy system. Each functional submodule can create multiple event producers and consumers as needed to generate or process events (i.e., data) on different themes. There is no calling relationship between functional submodules, and they can be merged into a single service according to the operating cycle, and interact with each other through the event framework layer.
[0034] In this embodiment, the service module is the core control unit of the service layer, mainly used for service registration mechanism, service association management and service health monitoring; The service registration mechanism is used to dynamically manage the lifecycle of all services in the system and supports plug-and-play functionality for services. Service association management is used to maintain the mapping relationship between services and functional modules, ensuring the correct execution of business logic; Service health monitoring is based on the service health management function submodule. Through multi-dimensional monitoring strategies (such as periodic heartbeat detection, response time statistics, etc.), it comprehensively grasps the operational status of each service. When a service anomaly is detected, the service recovery process (including service restart, resource reclamation, fault logging, etc.) is automatically triggered to ensure the continuous and stable operation of the system.
[0035] In this embodiment, as Figure 4 As shown, the various functional sub-modules located in the service layer interact with each other through the event framework layer. A single functional sub-module can contain multiple event producers with different topics, as well as multiple consumers that have subscribed to different topics. Producers send events to the event framework layer, and the events are placed in the event queue of the event framework layer. Subsequently, the events are distributed to consumers that have subscribed to this topic according to the subscription relationship.
[0036] Optionally, the service module also supports hot-swapping, meaning it can be dynamically added and removed during software runtime, dynamically loaded and unloaded, and flexibly configured according to task requirements.
[0037] 2. The event framework layer is used to build an internal data exchange mechanism for the system, specify that data flows in the form of events, and adopt a publish-subscribe pattern to achieve loosely coupled communication between functional modules.
[0038] In this embodiment, the event framework layer consists of an event queue module and an event management module; The event queue module employs a multi-topic hierarchical storage strategy, classifying and storing different types of event data (such as telemetry events, control command events, and abnormal alarm events) into independent queues according to their topics. For example, high-priority events (such as fault alarms and emergency control commands) have priority processing rights, ensuring that critical business operations can be responded to in a timely manner. The capacity and scheduling strategy of each event queue can be configured according to the needs of different task scenarios to adapt to different task scenarios. The event management module provides complete event lifecycle management, including: (1) Distribute the data in the queue to the subscribed consumers.
[0039] (2) Manage event producers and consumers by registering and maintaining each event source or event processing unit.
[0040] (3) By controlling event consumption permissions, ensure that each functional submodule can only receive and process specific topic events that it has subscribed to, thereby realizing subscription relationship management.
[0041] 3. The adaptation layer includes the operating system adaptation layer and the driver interface adaptation layer; it is used to shield the differences between the underlying hardware and the operating system, and provide a standardized and unified operating environment and device access interface for the upper event framework layer and service layer.
[0042] (1) The operating system adaptation layer adopts the adapter design pattern to implement specific adaptation modules for different real-time operating systems (such as SPACEOS, WingHui, VxWorks, etc.), and provides standardized interfaces for the event-driven layer and service layer, providing a consistent operating environment.
[0043] In this embodiment, the main adaptation content of the operating system adaptation layer includes: encapsulating interfaces for task creation, deletion, and scheduling of different operating systems; unifying the interface specifications for memory allocation and release; establishing communication mechanisms such as abstract message queues and semaphores; providing unified time acquisition and timer interfaces; and standardizing interrupt handling and registration processes.
[0044] Optionally, the operating system adaptation layer can also realize unified management and monitoring of system resources, including functions such as CPU usage statistics, memory usage analysis and task scheduling tracking, providing data support for system optimization and fault diagnosis.
[0045] (2) The driver interface adaptation layer adopts the hardware abstraction layer (HAL) technology to uniformly encapsulate the driver interfaces of various hardware devices and provide a standardized device access interface for the upper-layer service functions.
[0046] In this embodiment, the content to be adapted by the driver interface adaptation layer includes: unifying the access interfaces of various buses (such as CAN, SpaceWire, 1553B, etc.); standardizing the control interfaces of various peripherals (such as sensors, actuators, etc.); encapsulating the operation interfaces of different communication devices (such as S-band transceivers, X-band transponders, etc.).
[0047] As Figure 2 shown, based on the above service management system, the present invention proposes an event-driven satellite on-board software service management method, and its steps include, S1. Initialize and prepare the service management system.
[0048] S1.1. Execute driver initialization to complete the configuration and enablement of the driver interface between the service management system and the hardware device, and ensure that the hardware resources can be normally called by the system.
[0049] S1.2. Execute event framework layer initialization to create an empty event queue, producer / consumer registry, and routing table, and at the same time complete the allocation of relevant memory spaces and set the initial states of each component to the ready state.
[0050] S1.3. Execute service layer initialization to perform initialization operations on all services and their associated functional sub-modules, zero the service counter value, and verify whether each service has the necessary functions and parameters according to the static configuration table [Yin Hu 2] (as Figure 7 shown) to ensure that each service can meet the running configuration requirements and is in a startable state.
[0051] S2. Start and run the service management system.
[0052] S2.1. Start the event framework layer, start the event distribution task, and at the same time start the producer, consumer, and queue monitoring functions to make the event framework layer enter the continuous running state, and continuously check the situation of each topic event queue. If the queue is not empty, take out the head event of the queue and enter the distribution process.
[0053] In this embodiment, as Figure 5 shown, starting the event framework layer specifically includes: a. After entering the event framework layer startup link, start the event queue module and enter the continuous running state, and continuously execute the event distribution operation; among them, once an event is detected in the event queue, immediately distribute the event to the consumer subscribing to the event.
[0054] b. Start the event management module to listen for various registration requests in real time.
[0055] If a new theme registration request is detected, a corresponding event queue is added for the new theme, and the queue initialization configuration is completed; If a new producer registration request is detected, a unique identifier is assigned to the producer, and its information is entered into the producer registry for management. If a new consumer registration request is detected, first verify that the topic the consumer intends to associate with exists. If the verification is successful, assign a unique identifier to the consumer and add its information to the consumer's registry. If a consumer's request to subscribe to a topic is detected, first check if the target topic exists. If the check passes, update the association between the consumer and the topic in the routing table for maintenance.
[0056] Optionally, when a producer generates an event, the event framework layer also needs to verify the validity of the sent event. The steps include: a. After the producer generates an event, it sends the event to the event framework layer.
[0057] b. The event framework layer verifies the legality of the event and the legality of the topic.
[0058] Optionally, if an empty event is detected, the error type is determined to be INVALID_EVENT, the event is discarded directly, and the corresponding error log is recorded; If the topic associated with the event is found to be non-existent, the error type is determined to be INVALID_TOPIC, the delivery operation for the event is rejected, and the relevant error information is recorded. If both the event and the topic are valid, the normal event distribution process will begin, and the event management module will distribute the event to the corresponding consumer.
[0059] S2.2 Start the service layer, create an independent thread for each service according to the service dimension, and enable the service to start running. At the same time, start the service monitoring mechanism to monitor the running status of each service in real time. Once a service abnormality is detected, the service thread restart process is automatically triggered.
[0060] In this embodiment, as Figure 6 As shown, the service layer starts, and the specific steps include: 1. Service Launch Phase a. Start the service layer and start service modules in parallel; the system starts all basic services at the same time, such as telemetry service and bus service. Each basic service runs independently and does not block each other, ensuring service startup efficiency.
[0061] b. While starting the basic services, start the service management function submodule and allocate a separate thread to make it run independently of the basic services, so that it can focus on service management work.
[0062] 2. Service heartbeat monitoring and anomaly handling phase.
[0063] a. The service management submodule initializes the heartbeat monitoring function, enters a monitoring loop, and checks the last active time of each service every 2 seconds to obtain the detection results. b. Abnormal status is determined and handled based on the service active time.
[0064] In this embodiment, service heartbeat monitoring runs as a separate thread, and its algorithm flow specifically includes: It runs at a fixed period of T_monitor, whose value is set to 1 / 2 to 2 / 3 of the heartbeat timeout threshold T_heartbeat_timeout; for example, if T_heartbeat_timeout=3000ms, then T_monitor=1500ms.
[0065] After each wake-up, the service heartbeat monitoring thread traverses all initialized services in the global service registry services[], identifies services with the status RUNNING, and ignores services with the status INACTIVE and RECOVERING.
[0066] Perform heartbeat checks on services in the RUNNING state to identify abnormal states, including: 1) Get the current system clock t_current.
[0067] 2) Attempt to acquire the mutex lock of service S_i; if the lock acquisition fails (possibly because the service thread is holding it for a long time), abandon this check, log it, and check the next service; if the lock is successfully acquired, read S_i->last_heartbeat.
[0068] 3) Calculate the heartbeat interval: Δt = t_current - S_i->last_heartbeat.
[0069] 4) Release the mutex lock of service S_i and perform an abnormal state judgment on service S_i: if Δt>T_heartbeat_timeout, it is determined that the heartbeat of service S_i has timed out and an abnormality may have occurred; otherwise, it is determined that the heartbeat of service S_i is normal and no abnormality has occurred.
[0070] When the heartbeat of service S_i is determined to have timed out, check its historical recovery records.
[0071] Optionally, if S_i->restart_count >= N_max_retry (N_max_retry is the preset maximum number of retries, such as 5 times), the service is determined to be a permanent failure; the monitoring thread sets its status to INACTIVE, records a critical error log, and no longer attempts to recover, waiting for external intervention; if the last active time of the service is within a preset time (such as 5 seconds) from the current time, the service is determined to be running normally, and the monitoring status continues. In this embodiment, the graceful termination of an abnormal service aims to safely perform a "termination-cleanup-restart" operation on a service S_i that has been determined to be abnormal. The steps include: A1. State transition and thread termination request.
[0072] The service heartbeat monitor acquires the mutex lock for _i again; The state S_i->state is atomically changed from RUNNING to RECOVERING. This state bit is read by the main loop of the service thread. Once the service thread is not suspended and can execute the next loop, it will see this state and exit voluntarily, which is beneficial for subsequent join operations. Release the mutex lock on S_i. A2. Call os_thread_join(S_i->thread, T_join_timeout); this operation will block and wait for the service thread to exit naturally, and a waiting timeout is set (e.g., T_join_timeout = 100ms).
[0073] Optionally, os_thread_join returns success if the service thread exits normally within T_join_timeout; otherwise, os_thread_join returns failure. This means that the thread cannot be stopped softly.
[0074] A3. Regardless of whether os_thread_join is successful, call the os_thread_destroy function(S_i->thread) and set S_i->thread to NULL.
[0075] A4. Iterate through all functional modules of service S_i in order and call the cleanup function of each module to reclaim resources.
[0076] In this embodiment, the cleanup function of each module must release all private resources requested by the module during its init and run phases, including: (1) Release dynamic memory.
[0077] (2) Close the file descriptor.
[0078] (3) Release access rights to hardware peripherals (such as SPI, I2C).
[0079] (4) All mutexes (os_mutex_unlock) and semaphores held by this module.
[0080] A5. Reset and restart the service thread, which includes: Acquire the mutex lock for service S_i again and increment the restart counter: S_i->restart_count++; Iterate through all functional modules of service S_i, and call its init function again to re-request resources and restore it to the initial ready state; Call os_thread_create to create a new thread, execute the service_thread function, and assign the new thread handle to S_i->thread; Update the heartbeat timestamp S_i->last_heartbeat to the current time, and atomically change the service state S_i->state from RECOVERING to RUNNING; Release the mutex lock on service S_i. This concludes the graceful termination and recovery process, allowing service S_i to resume operation with a completely new thread and an initialized module state.
[0081] In this embodiment, during the cyclic monitoring of the service management submodule, it is also necessary to monitor whether there are any new service registration requests. The steps include: a. The service management component listens in real time for new service registration requests; b. If a new service registration request is received, first verify the legitimacy of the new service. Optionally, if the verification fails, the registration request for the new service is rejected, and the relevant rejection reason and log information are recorded; If the verification passes, a unique ServiceID is assigned to the new service, the new service information is added to the service registry, and the association between the new service and other related modules is maintained. Then the new service is started and included in the heartbeat monitoring scope, and managed according to the normal service monitoring process.
[0082] S3 is a cyclical service management system that monitors the running status and detects and receives stop signals.
[0083] S3.1 Enter the main loop monitoring state, continuously run in a loop, and monitor in real time whether a stop signal is received.
[0084] Optionally, if no stop signal is detected, the system remains running and continues to execute all preset functions; if a stop signal is detected, the system receives the stop signal, puts the system into a sleep state for a certain period of time (e.g., 5 seconds), stops all running services, and finally stops the event framework layer. After resource reclamation is completed, the system stops running.
[0085] The foregoing description and accompanying drawings fully illustrate embodiments of the invention to enable those skilled in the art to practice them. Other embodiments may include structural and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Some portions and features of some embodiments may be included or substituted for portions and features of other embodiments. Embodiments of the invention are not limited to the structures described above and shown in the drawings, and various modifications and changes can be made without departing from their scope. The scope of the invention is limited only by the appended claims.
Claims
1. An event-driven satellite space service management system, characterized in that, The system includes: a service layer, an event framework layer, and an adaptation layer; The service layer is used to generate or process events on different themes. It adopts a modular and service-oriented design and consists of a variable number of service modules, each of which contains one or more functional sub-modules. The service modules have service registration mechanisms, service association management, and service health monitoring functions. Each of the functional sub-modules follows the single responsibility principle and realizes data interaction through the event framework layer. The event framework layer consists of an event queue module and an event management module, which are used to build an internal data exchange mechanism for the system, specify that data flows in the form of events, and adopt a publish-subscribe pattern to achieve loosely coupled communication between various functional modules. The adaptation layer includes an operating system adaptation layer and a driver interface adaptation layer, which are used to shield the differences between the underlying hardware devices and the operating system, and provide a consistent operating environment and device access interface for the upper event framework layer and service layer. The operating system adaptation layer adopts the adapter design pattern to provide standardized interfaces for the event-driven layer and the service layer; the driver interface adaptation layer adopts hardware abstraction layer technology to uniformly encapsulate the driver interfaces of various hardware devices.
2. The event-driven satellite space service management system according to claim 1, characterized in that, The service registration mechanism is used to dynamically manage the lifecycle of all services in the system and supports plug-and-play services. The service association management is used to maintain the mapping relationship between services and functional modules; The service health monitoring is based on the service health management function submodule. It monitors the service operation status through a multi-dimensional monitoring strategy of periodic heartbeat detection and response time statistics. When a service anomaly is detected, a service recovery process is triggered.
3. The event-driven satellite space service management system according to claim 2, characterized in that, The service response process includes service restart, resource reclamation, and fault logging measures.
4. An event-driven satellite service management method, applied to the event-driven satellite service management system according to any one of claims 1-3, characterized in that, The method includes, Initialize and prepare the service management system; Start the service management system; The service management system runs in cycles, monitors its running status, and detects and receives stop signals.
5. The event-driven satellite space service management method according to claim 4, characterized in that, The initialization preparation of the service management system specifically includes... Perform driver initialization to complete the configuration and activation of the driver interface between the service management system and the hardware device; Perform event framework layer initialization, create an empty event queue, producer or consumer registry and routing table, complete the allocation of relevant memory space, and set the initial state of the event framework layer to the ready state. Perform service layer initialization, which initializes all services and their associated functional submodules.
6. The event-driven satellite space service management method according to claim 4, characterized in that, The process of starting the service management system specifically includes starting the event framework layer and starting the service layer.
7. The event-driven satellite space service management method according to claim 6, characterized in that, The startup event framework layer specifically includes, Start the event queue module and enter a continuous running state, continuously executing event dispatch operations; Start the event management module to listen for registration requests; these requests include new topic registration requests, new producer registration requests, new consumer registration requests, and consumer subscription requests. The startup service layer specifically includes: starting the service layer; performing service heartbeat monitoring; and handling anomalies.
8. The event-driven satellite space service management method according to claim 7, characterized in that, The startup event management module listens for registration requests, specifically including: if a new topic registration request is detected, adding a corresponding event queue for the new topic and completing the initialization configuration of the queue; If a new producer registration request is detected, a unique identifier is assigned to the new producer, and its information is entered into the producer registry for management. If a new consumer registration request is detected, the topic that the consumer intends to associate with is verified. If the verification is successful, a unique identifier is assigned to the consumer and added to the consumer registry. If a consumer's request to subscribe to a topic is detected, the subscription topic is verified. If the verification is successful, the association between the consumer and the subscription topic is updated in the routing table for maintenance.
9. The event-driven satellite space service management method according to claim 7, characterized in that, The startup service layer specifically includes a startup service layer and a parallel startup service module; Start the service management function submodule and allocate a separate thread; The aforementioned service heartbeat monitoring and anomaly handling specifically includes, The service management function submodule initializes the heartbeat monitoring function and enters the monitoring loop state, checking the last active time of each service at certain intervals. The status is determined and processed based on the last active time of the service.
10. The event-driven satellite space service management method according to claim 9, characterized in that, The status is determined and processed based on the last active time of the service, specifically including: If the last active time of the service is within the preset time from the current time, the service is considered to be running normally and monitoring will continue. If the last active time of the service is more than a preset time (e.g., 5 seconds) away from the current time, the service is determined to be abnormal. First, gracefully terminate the thread corresponding to the abnormal service, then re-initialize the abnormal service and try to restart it. If the restart is successful, the abnormal service will be brought back into the monitoring scope; if the restart fails, an alarm mechanism will be triggered, and the abnormal service will be isolated to avoid affecting the operation of other services.