A satellite software system and control method based on domain-driven design

Abstract

The present disclosure relates to the technical field of satellite software design, and discloses a satellite software system and control method based on domain-driven design, which standardizes and encapsulates heterogeneous functional single-machine devices on the satellite through the construction of an atomic service layer, and defines the calling mode of a business semantic interface in combination with a domain layer, can effectively solve the task arrangement rigidification problem caused by high module dependency under a traditional monolithic architecture, constructs a clear decoupling boundary between a satellite business domain model independent of underlying hardware and physical devices, and thus effectively improves the reuse rate and transplantation capability of satellite software assets among different model platforms. Through an application service layer, a task request is mapped to a business semantic of the domain layer, and in combination with a domain event triggering mechanism within the domain model, cross-subsystem and cross-satellite tasks can be executed in a dynamic arrangement manner, and effective isolation of an intersatellite coordination strategy and an underlying physical communication link is realized.

Description

Technical Field

[0001] This disclosure relates to the field of satellite software design technology, specifically to a satellite software system and control method based on domain-driven design. Background Technology

[0002] As the control center of a spaceborne system, satellite software's architecture directly determines the development cycle and on-orbit performance of modern satellite systems. With the rapid development of satellite networking and constellation trends, the traditional monolithic software architecture, which employs tight coupling between hardware and software and high dependence on functional modules, is gradually becoming unable to meet the needs of rapid commercial satellite development and the continuous evolution of overall constellation performance.

[0003] However, the existing architecture faces two major technical challenges: first, the deep interweaving of software and hardware, coupled with a lack of business logic abstraction, forces software to passively adapt to hardware, resulting in extremely high costs for cross-model reuse and porting; second, mission control logic and inter-satellite collaboration mechanisms are often hard-coded into specific underlying communication protocols, leading to rigid single-satellite mission orchestration and an inability to adapt to the elastic expansion requirements of constellation expansion and multi-satellite dynamic collaboration. Therefore, providing a satellite software system and control method that is deeply decoupled from hardware and software, supports dynamic mission orchestration, and possesses a highly scalable inter-satellite collaboration mechanism to improve the reusability of satellite software assets across different platform models and address the issues of rigid scheduling and limited performance in distributed networking and multi-task concurrent scenarios is a pressing technical problem in this field. Summary of the Invention

[0004] In view of this, this disclosure provides a satellite software system and control method based on domain-driven design to address how to improve the reusability of satellite software assets across different platform models, as well as the problems of scheduling rigidity and performance limitations in distributed networking and multi-task concurrent scenarios.

[0005] This disclosure provides a satellite software system based on domain-driven design, the system comprising: The atomic service layer is configured to abstract heterogeneous functional standalone devices on the satellite into independent atomic services and expose standardized atomic service interfaces to the outside world. The domain layer interacts with the atomic service layer and is configured to build a satellite business domain model independent of the underlying hardware. The domain layer calls standardized atomic service interfaces by defining business semantic interfaces, isolates business logic from underlying hardware operations, and triggers cross-system state transitions and business operations through domain events within the domain model. The application service layer interacts with the domain layer and is configured to receive task requests from external systems or satellites. It maps task requests to business semantics of the domain layer and performs process orchestration and distributed collaborative scheduling of cross-system and / or cross-satellite tasks by calling services provided by the domain layer.

[0006] This disclosure also provides a satellite software control method based on domain-driven design, the method comprising: The heterogeneous functional stand-alone devices on the satellite are hardware abstracted, encapsulated into independent atomic services, and standardized atomic service interfaces are exposed to the outside world. Construct a satellite service domain model independent of the underlying hardware, call standardized atomic service interfaces by defining business semantic interfaces, isolate business logic from underlying hardware operations, and trigger cross-system state transitions and business operations through domain events within the domain model; Receive task requests from external systems or on-board systems, map the task requests to corresponding business semantics, and perform process orchestration and distributed collaborative scheduling of cross-system and / or cross-satellite tasks by calling services provided by the domain model.

[0007] In another aspect, this disclosure also provides an electronic device, including: a memory for storing a computer program; The processor is used to implement the steps of the above-described satellite software control method based on domain-driven design when executing computer programs.

[0008] This disclosure also provides a computer-readable storage medium storing computer instructions for causing a computer to implement the aforementioned domain-driven design-based satellite software control method.

[0009] This disclosure also provides a computer program product, including computer instructions for causing a computer to execute the aforementioned domain-driven design-based satellite software control method.

[0010] The satellite software system and control method based on domain-driven design in the above embodiments of this disclosure firstly, by constructing an atomic service layer to standardize the encapsulation of heterogeneous functional single-machine devices on the satellite, and combining the calling method of the business semantic interface defined by the domain layer, the rigid task orchestration problem caused by the high dependence of modules under the traditional monolithic architecture can be effectively solved. A clear decoupling boundary is constructed between the satellite business domain model and physical equipment, which is independent of the underlying hardware, thereby effectively improving the reusability and portability of satellite software assets across different models and platforms.

[0011] Secondly, by mapping task requests to business semantics in the domain layer through the application service layer and combining the domain event triggering mechanism within the domain model, cross-system and cross-satellite tasks can be executed in a dynamic orchestration manner. This not only eliminates the architectural solidification interference caused by hardcoding the collaborative logic into the underlying communication protocol in existing technologies, but also achieves effective isolation between inter-satellite collaborative strategies and underlying physical communication links. Furthermore, it eliminates the need for additional customized hardware modifications to existing satellite service buses or inter-satellite communication equipment, thereby improving the scheduling flexibility and overall operational efficiency of the satellite system in distributed networking and multi-task concurrent scenarios. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this disclosure, the accompanying drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 An exemplary schematic diagram of the architecture of a satellite software system based on domain-driven design, according to an embodiment of this disclosure, is shown. Figure 2 This is a flowchart illustrating a satellite software control method based on domain-driven design provided in an embodiment of this disclosure; Figure 3 This is a cross-layer call timing diagram of a satellite software control method based on domain-driven design provided in this embodiment of the disclosure; Figure 4 This is a flowchart illustrating the function of the anti-corrosion layer in a camera startup embodiment of a satellite software control method based on domain-driven design, as provided in this disclosure. Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0015] As the control center of a spaceborne system, the quality of satellite software architecture design directly determines the performance and development cycle of modern satellite systems. With the rapid development of satellite networking and constellation trends, system functions are becoming increasingly complex. The traditional monolithic software design, which employs tight coupling between hardware and software and high dependence on functional modules, has become the core contradiction restricting the rapid, low-cost, and mass production of commercial satellites and the continuous evolution of the overall constellation performance.

[0016] For example, related technologies often employ customized monolithic software architectures, attempting to directly control and schedule individual underlying functionalities through specific business logic code. While some related technologies achieve basic inter-satellite link communication and simple collaboration when facing constellation networking requirements, they often use fixed, hard-coded communication protocols and customized collaboration logic to complete multi-satellite interactions.

[0017] While existing technologies have achieved basic single-satellite on-orbit operation and preliminary inter-satellite communication in form, they lack a unified service abstraction and isolated encapsulation of business logic in substance. The control logic and business rules of each functional unit are intertwined, resulting in a rigid collaborative mode that is difficult to dynamically adjust. This not only fails to support the flexibility of software-defined constellations but also faces the risk of complete refactoring when the constellation scale expands or the mission changes.

[0018] In summary, the following problems often exist in related technologies: 1. The system suffers from high functional coupling and poor software reusability. Related technologies lack unified standardized interfaces and business logic abstractions, with business rules and underlying control logic scattered and intertwined across various modules. Modification of any single module can easily disrupt system stability, making it difficult to reuse software assets across different satellite models and resulting in significant duplication of development work for new models.

[0019] 2. The rigid task orchestration and limited global coordination and fault handling capabilities stem from the fact that task logic is often hard-coded into the program, and each module maintains its own status information, resulting in a lack of a unified state view. This not only makes it difficult for the architecture to support the concurrent execution and dynamic scheduling of complex multi-tasks, but also greatly limits the system's ability to autonomously diagnose and handle faults in complex on-orbit environments.

[0020] 3. Inter-satellite coordination capabilities are rigid and lack scalability. Existing inter-satellite coordination relies heavily on customized underlying code and lacks a unified orchestration mechanism for cross-satellite missions. When the constellation size expands, member satellite models are updated, or coordination missions change, the underlying code needs to be modified for adaptation, making it impossible to achieve dynamic multi-satellite coordination and distributed mission scheduling, which seriously restricts the continuous evolution of the overall constellation performance.

[0021] To address the aforementioned issues, various embodiments of this disclosure provide a satellite software system based on domain-driven design. The system includes: an atomic service layer configured to abstract heterogeneous onboard functional single-machine devices into independent atomic services and expose standardized atomic service interfaces; a domain layer interacting with the atomic service layer, configured to construct a satellite service domain model independent of the underlying hardware. The domain layer calls standardized atomic service interfaces by defining business semantic interfaces, isolating business logic from underlying hardware operations, and triggering cross-subsystem state transitions and business operations through domain events within the domain model; and an application service layer interacting with the domain layer, configured to receive external or onboard task requests, map task requests to the business semantics of the domain layer, and perform cross-subsystem and / or cross-satellite task process orchestration and distributed collaborative scheduling by calling services provided by the domain layer.

[0022] It should be noted that, in the description of this disclosure, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this disclosure are used to distinguish similar objects and are not used to describe a particular order or sequence.

[0023] To enable those skilled in the art to better understand the present disclosure, the present disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] Please refer to Figure 1 , Figure 1 An exemplary schematic diagram of the architecture of a satellite software system based on domain-driven design, according to an embodiment of this disclosure, is shown. Figure 1 As shown, the system includes: Atomic Service Layer 101 is configured to abstract heterogeneous functional standalone devices on the satellite into independent atomic services and expose standardized atomic service interfaces to the outside world.

[0025] In this embodiment, the atomic service layer 101, as a decoupling unit between software and hardware, can include multiple standardized drivers and protocol conversion units for the underlying physical links. This allows for the abstraction and extraction of the native instructions and private operation logic of physical hardware from different manufacturers and with different communication systems on the satellite, shielding the details of underlying bus communication and differences in hardware registers, and converting them into standardized service forms that can be independently invoked.

[0026] Based on the above mechanism, the atomic service layer 101 builds a unified service call interface on top of the physical hardware, thereby eliminating the dependence of the upper-layer software on specific hardware models.

[0027] For example, for different types of attitude sensors, the atomic service layer 101 will unify and abstract the different raw data stream parsing and device configuration instructions into a unified data acquisition service and initialization service, and provide a consistent interaction protocol to the upper layer.

[0028] Domain layer 102 interacts with atomic service layer 101 and is configured to build a satellite business domain model independent of the underlying hardware. Domain layer 102 calls standardized atomic service interfaces by defining business semantic interfaces, isolates business logic from underlying hardware operations, and triggers cross-system state transitions and business operations through domain events within the domain model.

[0029] In this embodiment, the domain layer 102 may include a set of hardware-independent business rules built based on Domain-Driven Design (DDD) and an event publishing and subscription interaction mechanism.

[0030] Specifically, the domain layer 102 uses the DDD method to abstract the complex operational constraints and control logic of the satellite into a logical model independent of the physical hardware.

[0031] In this architecture, Domain Layer 102 serves as the central hub for the overall satellite business logic. It issues instructions to the lower layers through predefined business semantic interfaces. These interfaces express business intent but do not contain specific device driver parameters, ensuring that business operations are only oriented towards functional semantics and are unaware of the underlying physical implementation. Simultaneously, this layer utilizes an event-driven approach instead of traditional hard-coded timing, enabling loosely coupled collaboration between various business units based on state changes.

[0032] For example, when the system determines that the current satellite's orbital position meets specific conditions based on business rules, domain layer 102 directly publishes a "entering the target orbital region" domain event within the model. Other business logic units that depend on this state, after listening to the event, decide whether to request the activation of relevant devices through the business semantic interface based on their own business rules, thus avoiding complex cross-module direct hardware calls throughout the process.

[0033] Application service layer 103 interacts with domain layer 102 and is configured to receive external or satellite-based task requests, map task requests to the business semantics of domain layer 102, and perform process orchestration and distributed collaborative scheduling of cross-subsystem and / or cross-satellite tasks by calling the services provided by domain layer 102.

[0034] In this embodiment, the application service layer 103 may include a task instruction parsing module and process timing control logic.

[0035] Specifically, the application service layer 103 serves as the access and scheduling module for system task requests. This layer is responsible for parsing and mapping task requests from external sources (such as macro-level instructions from ground control stations or collaborative requests from the constellation network) or those generated autonomously on-board into specific business flows executable by the domain layer 102. By dynamically serializing and combining the various independent services provided by the domain layer 102, this layer achieves flexible orchestration and global coordination of complex task flows, effectively separating task scheduling logic from underlying execution actions, and supporting distributed scheduling of cross-system tasks within a single satellite and cross-satellite tasks between multiple satellites.

[0036] For example, when performing cross-satellite joint observation missions, the application service layer 103 breaks down the received joint mission request into the execution sequence of the current satellite, dynamically arranges the attitude alignment service and target imaging service in the domain layer 102, and maps the execution progress into the corresponding business feedback and sends it to the collaborative network, thereby completing the mission scheduling without modifying the underlying communication and control code.

[0037] The satellite software system and control method based on domain-driven design, as described in the above embodiments of this disclosure, firstly, by constructing an atomic service layer to standardize the encapsulation of heterogeneous functional single-machine devices on the satellite, and combining this with the calling method of the business semantic interface defined by the domain layer, can effectively solve the problem of rigid task orchestration caused by high module dependence in traditional monolithic architectures. A clear decoupling boundary is established between the satellite business domain model, independent of the underlying hardware, and the physical devices, thereby effectively improving the reusability and portability of satellite software assets across different platform models. Secondly, by mapping task requests to the business semantics of the domain layer through the application service layer, and combining this with the domain event triggering mechanism within the domain model, cross-subsystem and cross-satellite tasks can be executed in a dynamic orchestration manner. This not only eliminates the architectural rigidity interference caused by hard-coding collaborative logic into the underlying communication protocol in existing technologies, achieving effective isolation between inter-satellite collaborative strategies and the underlying physical communication links; but also eliminates the need for additional customized hardware modifications to existing satellite service buses or inter-satellite communication equipment, thereby improving the scheduling flexibility and overall operational efficiency of the satellite system in distributed networking and multi-task concurrent scenarios.

[0038] In one possible implementation of the above embodiments, the domain layer 102 includes multiple boundary context modules and a domain model; The boundary context module is established based on the professional domain division of the satellite subsystem and is used to achieve mutual logical isolation of the control logic of each functional unit. The domain model includes an aggregate root, which serves as the sole entry point for each subsystem's business unit. It encapsulates core satellite status information and, when receiving instructions from the application service layer 103 mapping, uses business rules to verify and intercept illegal instructions, thereby ensuring strong consistency of state during cross-subsystem collaboration.

[0039] In this embodiment, the domain layer 102 solves the problem of decreased system stability caused by the intertwining of control logic by breaking down the complex satellite subsystem logic into highly cohesive business units.

[0040] Specifically, the boundary context module can be the result of logical boundary division based on the professional functions of different satellite subsystems. Each boundary context module independently maintains its unique business logic, status and rules, and different modules are logically strongly isolated from each other.

[0041] By using this partitioning method, satellite software can transform the control logic of each individual device from an interleaved state to an autonomous state, ensuring that modifications to the rules of one system will not produce unexpected side effects on other systems.

[0042] For example, domain layer 102 can be divided into task management domain, motion control domain, energy security domain, data governance domain, and fault handling domain.

[0043] The task management domain is responsible for task command planning, the motion control domain is responsible for attitude and trajectory control logic, the energy security domain is responsible for power balancing, the data governance domain is responsible for storage and download strategies, and the fault handling domain is responsible for autonomous maintenance. The logic within each domain evolves independently, and modifying the rules of one domain will not cause system-wide instability.

[0044] Under this architecture, even if the charging strategy in the energy security domain is updated, there is no need to coordinate the modification of the attitude algorithm in the motion control domain, thus achieving independent evolution at the subsystem level.

[0045] Specifically, the domain model uses the aggregate root as the sole entry point for each subsystem's business unit, acting as a state consistency boundary. All external instructions targeting this business unit (such as requests from application service layer 103) must pass through the aggregate root's verification logic, thereby ensuring that all business operations comply with the satellite's current on-orbit constraints.

[0046] For example, when the imaging task aggregation root in the mission management domain receives a shooting command, it can automatically check the current energy level, solar angle and other constraints; if the conditions are not met, the aggregation root will directly intercept, effectively preventing illegal operations from damaging the satellite.

[0047] In addition, the aggregate root provides a reliable state source for the entire distributed software architecture by encapsulating the satellite's working mode, task execution steps, and other core states.

[0048] The satellite software system and control method based on domain-driven design in the above embodiments of this disclosure decouple the control logic using the boundary context module and establish the mandatory constraint boundary of the business rules using the aggregate root. This effectively solves the problems of logic intertwining, chaotic state management, and scattered business rules in traditional satellite software, and significantly improves the reusability and on-orbit safety assurance capability of the system.

[0049] In one possible implementation of the above embodiments, the domain layer 102 further includes an anti-corrosion layer; The anti-corrosion layer is used to define business semantic interfaces that maintain consistency with business semantics within the domain layer 102; The atomic service layer 101 is further configured to implement a business semantic interface, which encapsulates the underlying hardware parameters and control operations into a call response consistent with the business semantic interface, and implements the conversion between the parameters of the domain layer 102 and the underlying hardware instructions, so as to isolate the direct call between the domain layer 102 and the underlying hardware, so that the domain layer 102 only depends on the business semantic interface and does not know the underlying hardware implementation details.

[0050] In this embodiment, the domain layer 102 also includes an anti-corrosion layer, which is used to establish an isolation boundary between business logic and hardware implementation, and to ensure the stability of core business assets through a dependency inversion mechanism.

[0051] Specifically, the anti-corrosion layer defines a set of business semantic interfaces within the domain layer 102 that maintain consistency with business semantics. These interfaces are defined with satellite business functions in mind and do not contain any physical parameters of specific hardware or details of communication protocols.

[0052] The business logic within Domain Layer 102 is programmed only for these abstract interfaces, thus achieving a state of complete detachment of the business logic from the underlying hardware environment.

[0053] For example, the anti-corrosion layer can define standardized interfaces such as IPowerControlService (energy service interface) or IATtitudeControlService (attitude control service interface).

[0054] Furthermore, the atomic service layer 101 is configured to implement the business semantic interface defined in the anti-corruption layer. As the interface provider, the atomic service layer 101 is responsible for converting the business parameters issued by the domain layer 102 into control instructions that the underlying hardware can recognize. This conversion process includes data format encapsulation, physical address mapping, and generation of timing control logic.

[0055] In this way, the atomic service layer 101 isolates the domain layer 102 from direct calls to the underlying hardware, so that the domain layer 102 only needs to rely on the business semantic interface, while the complexity of hardware adaptation is pushed down to the atomic service layer 101.

[0056] For example, taking the payload "camera power-on" as an example, Domain Layer 102 initiates a business request through the interface ICameraHardwareAdapter defined in the anti-corrosion layer. This request carries parameters with business meaning (such as camera number and working mode). After receiving the request, the anti-corrosion layer interface implementation located in Atomic Service Layer 101 maps the business parameters to specific hardware physical channel identifiers and voltage control values ​​through its internal parameter conversion logic. Subsequently, Atomic Service Layer 101 constructs abstract control instructions and drives the underlying hardware driver interface (such as ICameraAtomicService) to perform physical power distribution actions. The execution result is finally encapsulated into standardized feedback information through the anti-corrosion layer interface and returned to Domain Layer 102.

[0057] Through the domain-driven design-based satellite software system and control method of the above embodiments of this disclosure, a clear logical defense is constructed between the domain layer 102 and the atomic service layer 101. This architecture design not only ensures the purity of the business model of the domain layer 102, but also enables the system to quickly adapt to heterogeneous hardware by changing the interface implementation of the atomic service layer 101, greatly improving the migration efficiency and reusability of satellite software across different hardware platforms.

[0058] In one possible implementation of the above embodiments, the application service layer 103 is used for cross-satellite task process orchestration and distributed collaborative scheduling, specifically including a session management module and a semantic and protocol adaptation module, wherein: The session management module is used to create and maintain the session context for cross-satellite collaborative tasks, and to record the identity, role division and execution stage of each member star participating in the cross-satellite collaborative task. The semantic and protocol adaptation module is used to extract cross-satellite domain events generated by the domain layer 102 into semantic payloads that are independent of the underlying communication system, and then send them to the target satellite through the atomic service layer 101 after selecting the communication protocol encapsulation format according to the communication capabilities of the target satellite. The semantic and protocol adaptation module is also used to receive external collaborative instructions from other satellites, decapsulate and extract the semantic payload, restore it to the local domain event, and inject it into the local domain layer 102 for business logic processing.

[0059] In this embodiment, the application service layer 103 acts as a collaborative control layer between the single-satellite business logic and the constellation network, which solves the problem of limited scalability caused by the deep binding of inter-satellite collaborative logic and the underlying physical communication protocol.

[0060] Specifically, the session management module is responsible for creating an independent runtime context for each cross-satellite mission to track the dynamic process of multi-satellite collaboration. For example, when performing a multi-satellite relay tracking mission of a moving ground target, the application service layer 103 that initiates the mission creates a relay tracking session, includes other satellite nodes participating in the mission in the session context, and assigns role settings (such as setting this satellite as the first executing satellite, satellite B as the backup satellite, and satellite C as the data relay satellite).

[0061] This mechanism supports process management for multiple stars participating in complex collaborative tasks simultaneously.

[0062] Furthermore, the semantic and protocol adaptation module is responsible for smoothing out the underlying communication differences during cross-satellite interactions. On the one hand, it transforms business semantics into underlying communication data, and on the other hand, it restores the underlying communication data back to business semantics.

[0063] For example, when the satellite completes target acquisition, the domain layer 102 generates a "target acquired" domain event. The semantic and protocol adaptation module extracts the service attributes of this event (such as target coordinates and timestamp) into a standard semantic payload, and encapsulates it into the CCSDS space data link protocol format according to the link type supported by satellite B before sending it.

[0064] Conversely, when satellite B receives the data packet, it performs protocol decapsulation and semantic restoration, generates a "takeover target" domain event locally, and injects it into the service bus, thereby triggering satellite B's attitude preset and payload warm-up logic.

[0065] The satellite software system and control method based on domain-driven design, as described in the above embodiments of this disclosure, achieve complete isolation between inter-satellite cooperation strategies and the underlying communication system. Even if the inter-satellite link protocol is upgraded in subsequent constellations (such as from microwave link to laser link), only the communication driver needs to be replaced at the atomic service layer 101. The upper-layer cooperative sessions and business semantic interactions do not require any code modification, effectively ensuring system scalability when the network scales up.

[0066] In one possible implementation of the above embodiments, the application service layer 103 further includes a situational awareness module and an anomaly handling module, wherein: The situational awareness module is used to maintain a real-time constellation collaborative status view by subscribing to cross-satellite domain events. The status view records the current task status, health status, and resource availability of each member star, providing cross-satellite situational awareness support for autonomous task allocation and conflict avoidance. The exception handling module is used to monitor the task lifecycle status in the session context in real time, and when it is determined that the task execution timeout or resource conflict exception occurs, it will autonomously call the fault handling service provided in the domain layer 102 to trigger the security mode switch or single-machine failover mechanism.

[0067] In this embodiment, the application service layer 103 enhances the constellation's autonomous collaborative decision-making and fault-tolerant recovery capabilities under dynamic environments and sudden failures by constructing a global situational awareness and closed-loop anomaly monitoring mechanism.

[0068] Specifically, the situational awareness module constructs a lightweight global data reference model by collecting state synchronization events within the constellation network.

[0069] For example, in a relay observation scenario, the situational awareness module records and updates the status view in real time, clearly indicating that satellite A is in "camera occupied" and in normal health status, while satellite B is in "standby and resource idle" status. This cross-satellite situational data provides real-time data support for autonomous path planning, dynamic task allocation, and potential resource conflict detection.

[0070] Furthermore, the anomaly handling module leverages the aforementioned session management and situational awareness data to perform system-level fault-tolerant intervention. For example, assuming that during the handover of control in relay observation, the anomaly handling module detects a command response timeout in backup satellite B, it can determine that an anomaly has occurred in the current collaborative session. At this time, the module autonomously invokes the fault handling service, terminates the handover waiting to satellite B, and upgrades relay satellite C's role to the primary execution satellite in real time to continue tracking the mission; or, depending on the severity of the timeout, it triggers a safety mode switching command for the relevant abnormal unit to isolate the fault.

[0071] The satellite software system and control method based on domain-driven design, as described in the above embodiments of this disclosure, endow the satellite software system with cross-satellite situational awareness and autonomous reconfiguration capabilities without ground station intervention. This design breaks through the limitations of traditional architectures that rely on ground commands for fault diagnosis, significantly improving the reliability of distributed task execution and the overall survivability of the constellation.

[0072] In one possible implementation of the above embodiments, the atomic service layer 101 includes the following categories of atomic services: Navigation and control atomic services are used to provide attitude determination and control, orbit control and maneuvering, and navigation and positioning. Platform-supported atomic services are used to provide power management, thermal control management, time reference, and satellite management. Communication and link-related atomic services are used to provide telemetry and remote control, high-speed data transmission, and inter-satellite link networking; Data storage and management atomic services are used to provide large-capacity data storage and health status monitoring and early warning. The payload performs atomic services to provide drive control for payloads used in optical imaging, communication forwarding, or scientific exploration.

[0073] In this embodiment, the atomic service layer 101 standardizes and classifies the complex physical hardware set of the entire satellite and divides its capability boundaries, providing a complete basic functional matrix for the upper-layer business logic.

[0074] Specifically, according to the professional functions of satellite engineering, the atomic service layer 101 abstracts the heterogeneous single units into five standard service categories, respectively shielding the differences in communication bus, instruction set and electrical interface of the corresponding physical devices.

[0075] For example, navigation and control atomic services abstract star sensors, gyroscopes, flywheels, and other hardware into standardized attitude pointing control and orbit maintenance interfaces; platform support atomic services encapsulate solar panels, battery packs, and power distribution units into unified energy distribution and bus voltage regulation interfaces; communication and link atomic services shield the underlying modulation, demodulation, and encryption framing logic of telemetry and control transponders or inter-satellite communication terminals; data storage and management atomic services abstract bad block management of solid-state storage and the underlying file system into indistinguishable read, write, and access interfaces; and payload execution atomic services encapsulate various mission devices such as visible light cameras, infrared cameras, or radar probes into unified exposure, gain adjustment, or detection triggering interfaces.

[0076] The satellite software system and control method based on domain-driven design, as described in the above embodiments of this disclosure, completely constrain the private characteristics and driving logic of the underlying heterogeneous hardware within various atomic services. This structure ensures that the upper-layer software assets are completely unaware of the model and manufacturer differences of specific individual devices, effectively shortening the R&D and testing cycle of new satellite models and greatly reducing the software integration risks during later on-orbit hardware backup and replacement.

[0077] Further reference Figure 2 , Figure 2 This is a flowchart illustrating a satellite software control method based on domain-driven design provided in this disclosure embodiment, applied to the above-mentioned... Figure 1 In the domain-driven design-based satellite software system shown, the process of this method may include the following steps: Step S201 involves hardware abstraction of the heterogeneous functional stand-alone devices on the satellite, encapsulating them into independent atomic services, and exposing standardized atomic service interfaces to the outside world.

[0078] Step S202: Construct a satellite service domain model independent of the underlying hardware. By defining a business semantic interface to call a standardized atomic service interface, the business logic is isolated from the underlying hardware operation. The domain events within the domain model trigger the state transitions and business operations across subsystems.

[0079] Step S203: Receive external or satellite-based task requests, map the task requests to corresponding business semantics, and perform cross-system and / or cross-satellite task process orchestration and distributed collaborative scheduling by calling services provided by the domain model.

[0080] In one possible implementation of step S202 above, a satellite service domain model independent of the underlying hardware is constructed, including: establishing multiple boundary contexts based on the professional domain division of the satellite subsystem to achieve mutual logical isolation of the control logic of each functional unit; Configure an aggregate root in the domain model, using it as the sole entry point for each subsystem's business unit to encapsulate core satellite status information; and When receiving instructions from the mapping, the business rules are validated and illegal instructions are intercepted through the aggregate root to ensure strong consistency of state during the cross-system collaboration process.

[0081] By defining business semantic interfaces to call standardized atomic service interfaces, business logic is isolated from underlying hardware operations, specifically including: Define a business semantic interface that maintains consistency with business semantics; Implement the business semantic interface, encapsulating the underlying hardware parameters and control operations into call responses consistent with the business semantic interface; and This enables the conversion between parameters corresponding to business semantics and underlying hardware instructions, thereby isolating business logic from direct calls to the underlying hardware. This allows business logic to rely solely on the business semantic interface without being aware of the underlying hardware implementation details.

[0082] In one possible implementation of step S203 above, process orchestration and distributed collaborative scheduling for cross-subsystem and / or cross-satellite tasks are performed, specifically including: Create and maintain the session context for cross-star collaborative tasks, and record the identity, role division and execution phase of each member star participating in the cross-star collaborative task; Domain events generated across satellites are extracted into semantic payloads independent of the underlying communication system, and then sent to the target satellite after selecting the appropriate communication protocol encapsulation format based on the target satellite's communication capabilities; and It receives external collaborative instructions from other satellites, decapsulates and extracts semantic payloads, restores them to local domain events, and injects them into local business logic for processing.

[0083] In one possible implementation of the above embodiments, the method further includes: By subscribing to cross-star domain events, the constellation collaboration status view is maintained in real time. The status view records the current task status, health status and resource availability of each member star, providing cross-star situational awareness support for autonomous task allocation and conflict avoidance. The system monitors the task lifecycle status in the session context in real time and automatically invokes the fault handling service when a task execution timeout or resource conflict occurs, thereby triggering a security mode switch or single-machine failover mechanism.

[0084] In one possible implementation of step S201 above, the heterogeneous functional stand-alone devices on the satellite are hardware abstracted and encapsulated as independent atomic services, specifically including: Encapsulate heterogeneous functional standalone devices on the satellite into the following categories of atomic services: Navigation and control atomic services are used to provide attitude determination and control, orbit control and maneuvering, and navigation and positioning. Platform-supported atomic services are used to provide power management, thermal control management, time reference, and satellite management. Communication and link-related atomic services are used to provide telemetry and remote control, high-speed data transmission, and inter-satellite link networking; Data storage and management atomic services are used to provide large-capacity data storage and health status monitoring and early warning. The payload performs atomic services to provide drive control for payloads used in optical imaging, communication forwarding, or scientific exploration.

[0085] In one specific embodiment, further reference is made to Figure 3 , Figure 3 This is a cross-layer call timing diagram of a satellite software control method based on domain-driven design provided in this disclosure embodiment, wherein: The first stage is the task self-planning stage, which includes steps 1 to 4.

[0086] Specifically, in step 1, the application service layer periodically calls the navigation data acquisition service (such as Get_Navigation_Data) of the navigation and control class in the atomic service layer to obtain and receive the returned satellite position data; In step 2, the application service layer internally determines that the satellite is about to enter the preset target observation area based on the acquired satellite position data; In step 3, the application service layer initiates a call to the task management domain in the domain layer (such as CreateTask(ImagingMission)) to create the imaging task aggregation root; In step 4, the task management domain autonomously calculates and fills in key parameters such as the execution time T0 and the target pointing quaternion in the task aggregate root based on the target coordinates, thus completing task instantiation.

[0087] The second stage is the self-constraint verification and logic orchestration stage, which includes steps 5 to 7.

[0088] Specifically, before the imaging task is issued and executed, the domain layer performs security checks through logical calls across subsystem domains: In step 5, the task management domain calls the power check service from the energy assurance domain within the domain layer and obtains the returned power status. In step 6, the task management domain calls the attitude check service from the motion control domain inside the domain layer and obtains the returned attitude feasibility status. In step 7, after the constraint verification is passed, the task orchestration service (such as TaskOrchestrator) in the task management domain generates a logical sequence composed of specific atomic service interfaces and returns the task execution sequence to the application service layer.

[0089] The third stage is the task collaborative execution stage, which includes steps 8 to 14.

[0090] Specifically, after entering the task execution window, the application service layer drives the underlying physical actions according to the execution sequence: In step 8, the application service layer calls the power switch control service of the power management class in the atomic service layer (e.g., Set_Power_Switch is ON) to turn on the camera power supply channel and obtain feedback that the power supply is successful. In step 9, the application service layer calls the attitude pointing control service (such as Start_Attitude_Pointing) of the navigation and control class in the atomic service layer to drive the underlying actuators to make the satellite point to the target; In step 11, after determining that the attitude maneuver is in place, the motion control domain issues an attitude lock domain event (the physical state response triggers the issuance of the event during the execution of this logic sequence). In step 12, the application service layer receives notifications of the aforementioned gesture locking domain events through an event subscription mechanism; In step 13, after confirming that the pointing accuracy meets the standard, the application service layer calls the camera exposure imaging service (such as Execute_Capture) of the optical imaging class in the atomic service layer at execution time T0. In step 14, on the one hand, the camera exposure imaging service performs the physical action of exposure imaging and returns the original image data to the application service layer; on the other hand, after the application service layer obtains the image data, it synchronously calls the data storage management service of the data storage class (such as Save_Image_Data) to store the original image data into the solid-state storage and obtains the storage success feedback.

[0091] The fourth stage is the task archiving and attitude adjustment stage, which includes steps 16 to 20.

[0092] Specifically, after the imaging and storage processes are completed, the system enters a closed business loop: In step 16, the application service layer sends a command to the attitude pointing control service (e.g., Start_Attitude_Pointing is set to Sun). In step 17, the attitude pointing control service performs the physical action of sun orientation attitude adjustment and returns sun orientation completion feedback to ensure that the energy system obtains maximum light efficiency. In step 18, the application service layer calls the power switch control service to turn off the camera power supply channel (e.g., Set_Power_Switch is set to OFF) and obtains power-off feedback to release resources; In step 19, the application service layer sends an update task status instruction (such as UpdateTaskStatus being set to Complete) to the task management domain. The domain layer then updates the status of the task aggregate root to Complete and returns a success feedback. In step 20, the application service layer confirms that the overall resource management and status update are complete, and the task is executed in a closed loop.

[0093] In yet another specific embodiment, please refer to Figure 4 , Figure 4 This is a flowchart illustrating the function of the anti-corrosion layer in a camera startup embodiment of a satellite software control method based on domain-driven design, as provided in this disclosure. Step 1 is the stage of initiating a business request.

[0094] Specifically, the application service layer sends an instruction to the domain layer: "Camera power on," initiating a functional request at the pure business logic level.

[0095] Step 2 is the stage of receiving application service layer business requests and executing business logic.

[0096] Specifically, the domain layer calls the code logic "handlePowerOnCommand(cameraId="CAM-01")" through its internal domain layer response entry point. Its semantics are to process the power-on control command of the camera with device identifier CAM-01. Subsequently, this entry point triggers the corresponding Camera aggregate root to execute the code logic "camera.powerOn()", which has the semantics of the camera aggregate root entity initiating a power-on action.

[0097] Before performing the above power-on actions, the camera aggregation root performs multiple business rule constraint checks, specifically including: Execute the logic of "checking if the current status is OFF" to confirm that the device is not in the powered-on state; The code logic "via EnergyService.hasSufficientPower(50.0)" is executed, which means calling the energy service to verify whether the current total satellite energy level meets the power consumption requirement of 50.0 units. The code logic "via TemperatureService.isWithinRange()" is executed, which means calling the temperature service to verify whether the current physical temperature is within the safe operating range.

[0098] After all constraints are verified, the camera aggregation root executes the "state change: OFF -> POWERING_ON" logic, officially changing the current logical state of the device from the off state to the power-on state.

[0099] Step 3 is the stage of defining standardized interfaces.

[0100] Specifically, the anti-corruption layer within the domain layer establishes the "interface definition: ICameraHardwareAdapter", which is the standard interface for camera hardware adapters. This interface defines the "CommandResult powerOn()" code logic, which is a pure business operation to turn on the camera. It also stipulates that when this method calls "CameraHardwareAdapter.powerOn()" to the underlying layer, it must "return a CommandResult{success, message,errorCode}" data object. This means that it is mandatory to return a standard result object containing a boolean execution status, prompt message, and error code, ensuring that this layer does not involve any private driver details of the underlying hardware devices.

[0101] Step 4 is the stage of implementing standardized interfaces at the domain layer.

[0102] Specifically, the atomic service layer is configured to provide the physical code for the "anti-corrosion layer interface implementation: CameraHardwareAdapter". This implementation module receives the pure business semantic call instruction "CommandResult powerOn()" (semantically meaning to perform the camera opening operation) issued by the domain layer, serving as the physical receiving point for cross-layer instruction parsing.

[0103] Step 5 is the stage for implementing parameter conversion and constructing abstract layer instructions.

[0104] Specifically, within the interface implementation logic of the atomic service layer, the code logic of "ParameterConverter.convert(businessParams, hardwareType, operationType)" is executed first. Its semantics are to convert the pure business parameters passed from the domain layer into the physical hardware parameters required for the target hardware type and specific operation type through the parameter converter. Subsequently, the code logic of "CommandBuilder.buildCommand(commandType=CommandType.POWER_ON, parameters=hardwareParams, priority=CommandPriority.HIGH)" is executed. Its semantics are to generate a low-level abstract control instruction containing a command type of power-on, the aforementioned physical hardware parameters, and a high scheduling priority through the instruction builder.

[0105] Step 6 is the stage of calling the atomic service interface and returning the result.

[0106] Specifically, the atomic service layer internally calls a specific camera atomic service interface "ICameraAtomicService" and passes in the underlying control command constructed above to execute the code logic "CommandResultexecuteCommand(CameraCommand command)". Its semantics are to execute the camera command with hardware control instructions and obtain the return result, thereby driving the underlying hardware to perform the actual physical power distribution action.

[0107] After the physical action is completed, the atomic service interface triggers the "execution result return" level by level to the upper level. The specific data object returned is "CommandResult{success=true, message="Camera power onsuccessful", errorCode="SUCCESS", executionTime=1250}", which means that the current physical execution status is successful, the feedback information is "camera power on successfully", the system error code is a normal success status, and the execution time of the underlying action is 1250 milliseconds.

[0108] The execution result is encapsulated and transmitted back to the camera aggregation root of the domain layer through the interface of the anti-corrosion layer. Finally, the domain layer returns the command feedback result in a unified format to the application service layer that initiated the request, thus completing the cross-layer call closed loop of the camera power-on service.

[0109] It should be noted that the above-described satellite software system based on domain-driven design, when implementing the corresponding domain-driven design-based satellite software control method, only uses the division of the above-described program modules as an example. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the above system can be divided into different program modules to complete all or part of the processing described above. Furthermore, the system provided in the above embodiments and the corresponding... Figure 2 The embodiments of the methods shown belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0110] This disclosure also provides an electronic device having the above-described features. Figure 1 The satellite software system shown is based on domain-driven design.

[0111] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure.

[0112] The following is a detailed reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from memory 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device. The processor 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0113] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0114] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 509, or installed from memory 508, or installed from ROM 502. When the computer program is executed by processor 501, it performs the functions defined in the domain-driven design-based satellite software system of embodiments of this disclosure.

[0115] Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0116] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the domain-driven design-based satellite software system shown in the above embodiments is implemented.

[0117] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0118] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A satellite software system based on domain-driven design, characterized in that, The system includes: The atomic service layer is configured to abstract heterogeneous functional standalone devices on the satellite into independent atomic services and expose standardized atomic service interfaces to the outside world. The domain layer interacts with the atomic service layer and is configured to build a satellite service domain model independent of the underlying hardware. The domain layer calls the standardized atomic service interface by defining a business semantic interface, isolates business logic from underlying hardware operations, and triggers cross-system state transitions and business operations through domain events within the domain model. The application service layer interacts with the domain layer and is configured to receive external or satellite-based task requests, map the task requests to the business semantics of the domain layer, and perform process orchestration and distributed collaborative scheduling of cross-subsystem and / or cross-satellite tasks by calling the services provided by the domain layer.

2. The system according to claim 1, characterized in that, The domain layer includes multiple boundary context modules and the domain model; The boundary context module is established based on the professional domain division of the satellite subsystem and is used to achieve mutual logical isolation of the control logic of each functional unit. The domain model includes an aggregate root, which serves as the sole entry point for each subsystem's business unit. This aggregate root encapsulates core satellite status information and, when receiving instructions mapped from the application service layer, intercepts illegal instructions through business rule verification to ensure strong consistency of state during cross-subsystem collaboration.

3. The system according to claim 1 or 2, characterized in that, The field layer also includes an anti-corrosion layer; The anti-corrosion layer is used to define the business semantic interface that maintains consistency with business semantics within the domain layer. The atomic service layer is further configured to implement the business semantic interface, which encapsulates the underlying hardware parameters and control operations into a call response consistent with the business semantic interface, and implements the conversion between domain layer parameters and underlying hardware instructions, so as to isolate the direct call between the domain layer and the underlying hardware, so that the domain layer only depends on the business semantic interface and does not know the underlying hardware implementation details.

4. The system according to claim 1, characterized in that, The application service layer is used for cross-satellite mission orchestration and distributed collaborative scheduling, specifically including a session management module and a semantic and protocol adaptation module, wherein: The session management module is used to create and maintain the session context of cross-satellite collaborative tasks, and to record the identity, role division and execution stage of each member star participating in the cross-satellite collaborative task. The semantic and protocol adaptation module is used to extract cross-satellite domain events generated by the domain layer into semantic payloads that are independent of the underlying communication system, and then send them to the target satellite through the atomic service layer after selecting the communication protocol encapsulation format according to the communication capabilities of the target satellite. The semantic and protocol adaptation module is also used to receive external collaborative instructions from other satellites, decapsulate and extract the semantic payload, restore it to the local domain event, and inject it into the local domain layer for business logic processing.

5. The system according to claim 4, characterized in that, The application service layer also includes a situational awareness module and an anomaly handling module, wherein: The situational awareness module is used to maintain a constellation collaboration status view in real time by subscribing to cross-star domain events. The status view records the current task status, health status and resource availability of each member star, providing cross-star situational awareness support for autonomous task allocation and conflict avoidance. The exception handling module is used to monitor the task lifecycle status in the session context in real time, and when it is determined that the task execution timeout or resource conflict exception occurs, it autonomously calls the fault handling service provided in the domain layer to trigger the security mode switch or single-machine failover mechanism.

6. The system according to claim 1, characterized in that, The atomic service layer includes the following categories of atomic services: Navigation and control atomic services are used to provide attitude determination and control, orbit control and maneuvering, and navigation and positioning. Platform-supported atomic services are used to provide power management, thermal control management, time reference, and satellite management. Communication and link-related atomic services are used to provide telemetry and remote control, high-speed data transmission, and inter-satellite link networking; Data storage and management atomic services are used to provide large-capacity data storage and health status monitoring and early warning. The payload performs atomic services to provide drive control for payloads used in optical imaging, communication forwarding, or scientific exploration.

7. A satellite software control method based on domain-driven design, characterized in that, The method includes: The heterogeneous functional stand-alone devices on the satellite are hardware abstracted, encapsulated into independent atomic services, and standardized atomic service interfaces are exposed to the outside world. Construct a satellite service domain model independent of the underlying hardware, call the standardized atomic service interface by defining a service semantic interface, isolate the service logic from the underlying hardware operation, and trigger the state transition and service operation across subsystems through domain events within the domain model; Receive external or satellite-based task requests, map the task requests to corresponding business semantics, and perform process orchestration and distributed collaborative scheduling of cross-system and / or cross-satellite tasks by calling the services provided by the domain model.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, used to implement the steps of the satellite software control method based on domain-driven design as described in claim 7 when executing the computer program.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the satellite software control method based on domain-driven design as described in claim 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the satellite software control method based on domain-driven design as described in claim 7.

Images