A distributed interactive spacecraft simulation system

Abstract

The application relates to a distributed interactive spacecraft simulation system, comprising a visual interactive subsystem, a simulation task management subsystem, a model calculation and service subsystem, a semi-physical interface subsystem and a data resource management subsystem. The model calculation and service subsystem realizes coordination and communication between distributed nodes through simulation middleware; the semi-physical interface subsystem serves as a special bridge and is responsible for protocol conversion and bidirectional real-time data transmission between a virtual simulation space and real physical hardware; all simulation models are encapsulated and deployed in the form of containerized microservices. The application overcomes the problem of complex deployment and maintenance caused by dependence on special clients in traditional HLA and other architectures, breaks through the limitation that similar tools such as STK can only perform static batch processing analysis and cannot intervene, adjust parameters and entities in real time during simulation running, and makes up for the shortage that existing aerospace simulation tools are disconnected from real hardware and in-orbit data.

Description

Technical Field

[0001] This invention relates to the field of spacecraft simulation technology, and to a distributed interactive spacecraft simulation system, particularly to a distributed interactive spacecraft simulation system that integrates B / S architecture (Browser / Server), distributed simulation, containerized microservices, and semi-physical virtual-physical interconnection. Background Technology

[0002] With the rapid development of the aerospace industry, the complexity of tasks such as multi-satellite networking, space target monitoring, spacecraft on-orbit operation and maintenance, and ground-based semi-physical experiments continues to increase. The industry has put forward higher requirements for spacecraft simulation platforms: they need to support cross-regional and cross-departmental multi-person collaborative modeling, enable real-time human-machine intervention in the simulation process, be compatible with digital prototypes, ground physical hardware, and real on-orbit telemetry data to carry out high-fidelity joint simulations, and at the same time take into account the engineering implementation needs such as rapid deployment, flexible expansion, and lightweight use.

[0003] Distributed Interactive Simulation (DIS) is a technological paradigm that interconnects geographically dispersed simulation nodes through standardized protocols and network communication to construct a coordinated and consistent comprehensive simulation environment. Its core features include node autonomy, decentralized control, and spatiotemporal consistency maintenance based on broadcast communication and a "heartbeat" mechanism. In this field, High Level Architecture (HLA) has become an internationally recognized engineering standard. HLA achieves interoperability between heterogeneous simulation nodes by defining components such as a federated object model and a runtime support framework. However, traditional distributed interactive simulation systems built on HLA or similar middleware typically employ a client / server architecture, leading to the following inherent drawbacks: 1) Complex system deployment and maintenance: Each simulation node requires dedicated client software and a complex runtime environment, making system deployment, upgrades, and cross-platform porting extremely difficult and resulting in high overall maintenance costs; 2) High barrier to entry and inconvenient collaboration: Users are bound to specific, complexly configured professional clients, making it difficult to achieve rapid access and flexible collaboration, and unable to support lightweight, real-time collaboration across regions and departments; 3) Disconnection from engineering development toolchains: Traditional DIS frameworks are mainly geared towards scenarios such as combat training and concept demonstrations. Their simulation models lack efficient and high-fidelity fusion channels with the digital prototype models used in the spacecraft engineering design phase and the real telemetry data generated during the on-orbit testing phase. The system struggles to directly utilize high-precision design models for simulation and to feed simulation results back into the design process, resulting in a problem of "simulation without realism" and "disconnect between simulation and application."

[0004] In the field of spacecraft mission analysis, there are commercial software such as Systems Tool Kit (STK). This type of software is essentially a high-precision parametric analysis and visualization tool. Its typical working mode is: the user pre-sets the orbits and parameters of all spacecraft, payloads, and targets, and obtains the final analysis results through a one-time calculation and simulation. Although STK is powerful, its core paradigm determines its fundamental shortcomings in achieving dynamic and interactive simulation: 1) Lack of "process simulation" and dynamic interaction capabilities: STK's operating mode is "batch processing" analysis, not "process simulation." Users cannot dynamically intervene during the entire simulation process from start to finish, and cannot inject new simulation entities, adjust existing entity parameters, or issue interactive commands in real time; that is, it does not support "human-in-the-loop" real-time simulation; 2) Lack of support for convenient and in-depth semi-physical simulation and real-time data closure: Although STK provides standardized data interfaces (such as STK Connect) that can exchange data with some external hardware or software to achieve a certain degree of hardware-in-the-loop simulation, its core architecture and original design intent are still a high-precision digital simulation and analysis environment. This positioning leads to significant limitations in supporting the testing and verification of spacecraft throughout their entire lifecycle; 3) Insufficient flexibility in model expansion and integration: Although STK provides secondary development interfaces, the deep integration and flexible scheduling of user-defined models are still limited by its closed framework. New software deployment and isolation technologies, such as containerization, are difficult to apply natively within its system, limiting the rapid integration and elastic scaling of complex custom simulation models.

[0005] In summary, the two existing technical solutions are fragmented and have their own limitations: on the one hand, the distributed interactive simulation architecture represented by HLA, although it supports interaction and distribution, is cumbersome and has weak integration with engineering practice; on the other hand, professional aerospace analysis software represented by STK, although the model is accurate, is static and closed, and lacks dynamic interaction and virtual-real integration capabilities. Summary of the Invention

[0006] To overcome the complex deployment and maintenance issues caused by the reliance on dedicated clients in traditional architectures such as HLA, and to break through the limitations of tools like STK which can only perform static batch analysis and cannot intervene in real time to adjust parameters and entities during simulation, this invention provides a distributed interactive spacecraft simulation system. Specifically, it provides a distributed interactive spacecraft simulation system that integrates B / S architecture, distributed simulation, containerized microservices, and semi-physical virtual-physical interconnection. This system adopts a pure B / S architecture as a unified access point and integrates the concept of distributed interactive simulation with microservice-based model management technology. The core of this system lies in its four-layer architecture of five systems working together, including: a visualization interaction subsystem, a simulation task management subsystem, a model calculation and service subsystem, a semi-physical interface subsystem, and a data resource management subsystem. Among them, the model calculation and service subsystem realizes the coordination and communication between distributed nodes through simulation middleware; the semi-physical interface subsystem acts as a dedicated bridge, responsible for protocol conversion and bidirectional real-time data transmission between the virtual simulation space and real physical hardware; all simulation models are encapsulated and deployed in the form of containerized microservices.

[0007] This invention provides a distributed interactive spacecraft simulation system, comprising: The visualization and interaction subsystem is configured to provide a unified browser-based human-computer interaction interface, collect users' simulation operation commands (simulation configuration, real-time control, and other interactive commands) and output them outwards, and receive the returned simulation situation data to complete the three-dimensional visualization display. The simulation task management subsystem is configured to receive simulation operation instructions issued by the visualization interaction subsystem, complete scenario analysis and driving, scheduling of computing resources and model services, comprehensive evaluation of simulation performance, issue simulation execution instructions, forward hardware control instructions, and summarize lower-level computation and hardware interaction data before sending them back to the visualization interaction subsystem for display. The model computation and service subsystem is configured to receive the simulation execution instructions, schedule the model container service group, perform distributed simulation computation, send the computation results back to the simulation task management subsystem, and retrieve storage resources as needed. The semi-physical interface subsystem is configured to receive the hardware control commands, perform bidirectional protocol conversion between virtual simulation and real hardware, and send the actual hardware test data back to the simulation task management subsystem for simulation calculations; and The data resource management subsystem is configured to provide storage and retrieval support for model, configuration, and simulation data for the visualization interaction subsystem, simulation task management subsystem, model calculation and service subsystem, and semi-physical interface subsystem.

[0008] Furthermore, the visualization and interactive subsystem includes: A web-based 3D visualization portal, implemented using WebGL technology, is configured to render 3D scenes of spacecraft, space targets, orbits, and sensor fields of view, and to receive and present simulation dynamic data in real time; and The scenario editing and management console is configured to provide a graphical drag-and-drop interface for users to edit simulation scenarios, configure entity parameters, and execute real-time control commands such as starting, pausing, and stopping simulation tasks.

[0009] Furthermore, the simulation task management subsystem includes: The simulation scenario engine is configured to parse user-edited scenario files, convert the scenario files into internally executable event-sequence logic, and drive the entire simulation process. A resource scheduler is configured to dynamically manage and schedule model computing resources in the model computing and service subsystem according to predetermined needs, thereby achieving task allocation; and The performance evaluation engine has a built-in indicator calculation model and is configured to perform real-time or post-event comprehensive performance analysis and evaluation of simulation process and result data, generating quantitative reports.

[0010] Furthermore, the model calculation and service subsystem includes: The simulation middleware, configured to handle registration and discovery, message routing, time synchronization, and event distribution for all simulation nodes, is the core technology of distributed interactive simulation; and The model container service group consists of multiple containerized autonomous simulation model services. Each autonomous simulation model service encapsulates an independent professional domain model and interacts with the simulation middleware through a standard interface.

[0011] Furthermore, the specialized domain models include orbital dynamics models, attitude control models, synthetic aperture radar payload models, and space environment models.

[0012] Furthermore, the semi-physical interface subsystem includes: A semi-physical interface gateway, acting as a protocol conversion hub between the simulation world and the physical world, is configured to connect to the simulation middleware, converting virtual instructions into real hardware protocols and converting hardware feedback data into messages understandable by the simulation environment; and The protocol adapter library integrates drivers for various standard and custom physical layer communication protocols (such as CCSDS space link protocol, custom TCP / IP protocol, etc.) to ensure reliable connection with real satellite units or test equipment.

[0013] Furthermore, the data resource management subsystem includes: The simulation database, employing a relational or time-series database, is configured to store structured scenario configurations, model parameters, simulation process snapshots, performance evaluation results, and more. The spacecraft model repository uses object storage services and is configured to manage simulation model container images, 3D mesh files, geographic textures, and satellite design documents.

[0014] Furthermore, it also includes: A runtime interactive interface is configured to enable instruction interaction and data linkage during simulation execution; the runtime interactive interface includes: The scenario and interaction command interface is configured to transmit user-edited simulation scenario configuration data and real-time control commands during simulation operation between the visualization interaction subsystem and the simulation task management subsystem; that is, to transmit user-edited simulation scenario configuration data (scenario) and real-time control commands (such as start, pause, parameter adjustment) issued during simulation operation; the scenario and interaction command interface type is HTTP RESTFUL API and WebSocket; The real-time situation and assessment interface is configured to push the simulated entity state, simulation events, and performance evaluation indicators from the simulation task management subsystem to the visualization interaction subsystem for front-end visualization display; that is, to push the dynamic entity state, key events, and real-time performance evaluation indicators generated by the simulation to the front end for visualization display, and the real-time situation and assessment interface type is WebSocket. The scheduling instruction and event interface is configured to transmit simulation event sequences and computing resource scheduling control instructions to the model computing and service subsystem; that is, to transmit simulation event sequences generated by scenario parsing, and control instructions for computing resource scheduling and task allocation for the model service. The scheduling instruction and event interface type is HTTP RESTful API and gRPC. The model status and result interface is configured to send back the intermediate status of the simulation model, the calculation results, and the service health status to the simulation task management subsystem; that is, to feed back the intermediate status, final result data, and health status of each simulation model during the calculation process for upper-level monitoring and evaluation. The model status and result interface type is a message middleware topic. A virtual control command interface, configured to issue hardware control commands to the semi-physical interface subsystem, completes the conversion of simulation control logic into a standard hardware command format; that is, converts control logic generated in the simulation environment (such as attitude maneuver commands, load switching commands) into a standardized command format sent to the real hardware. The virtual control command interface type is internal message bus / gRPC; and The high-fidelity physical data interface is configured to transmit operational telemetry data collected by real satellite units and test equipment back to the simulation task management subsystem and complete the data format standardization conversion; that is, to convert real operational data such as telemetry and sensor readings collected from real satellite units or test equipment into a standardized data format that can be understood by the simulation environment. The high-fidelity physical data interface type is internal message bus / gRPC.

[0015] Furthermore, it also includes: The data resource access interface is configured to implement system simulation resource loading, data persistence, and historical data reuse; the runtime interaction interface includes: The resource retrieval / replay request interface is configured to initiate query and replay requests for models, scenarios, and historical simulation data to the data resource management subsystem; that is, the front end requests to obtain model files, scenario templates, and 3D model assets stored in the database, or submits a replay query for historical simulation data. The resource retrieval / replay request interface type is HTTP RESTful API. The evaluation data access interface is configured to store and query performance evaluation reports and indicator details data into the data resource management subsystem; that is, to store structured data such as comprehensive evaluation reports and indicator details generated after the simulation, or to query historical evaluation results for comparative analysis. The evaluation data access interface type is a database access interface. The process data persistence interface is configured to asynchronously store simulation process snapshots and operation logs into the simulation database of the data resource management subsystem; that is, during the simulation operation, key process snapshots, entity state change logs, interactive events and other pipeline data are asynchronously stored into the database for post-analysis. The process data persistence interface type is an asynchronous message queue, a batch database write interface. The model / scenario / historical data interface is configured to send the model, scenario, and archived simulation dataset required for simulation initialization to the visualization interaction subsystem and the simulation task management subsystem; that is, to respond to the front-end request and provide the initial data resources required for simulation, including model definition, scenario configuration and archived historical simulation dataset. The model / scenario / historical data interface type is HTTP RESTful API / file download service. A model / configuration data interface, configured for use during the system initialization phase, allows the data resource management subsystem to transmit model metadata, algorithm parameters, and system configuration information to the simulation task management subsystem; specifically, during system startup or task initialization, it provides the management subsystem with the necessary simulation model metadata, algorithm parameters, and system runtime configuration information. The model / configuration data interface type is HTTP RESTful API / configuration file. The model image and initial data interface is configured to distribute the container image, initial input file, and geospatial basic dataset from the data resource management subsystem to the model computing and service subsystem before the model container starts; that is, before the model container starts, it is provided with the required large binary files or datasets such as the container image, initial input file, and basic geospatial data, and the model image and initial data interface type is file.

[0016] Furthermore, the system adopts a four-layer architecture, which, from top to bottom, consists of an application layer, a business layer, a service layer, and a data layer. The application layer carries the visualization interaction subsystem (i.e., the application layer is the interaction interface between the system and the user, configured to receive simulation operation commands from the user and send them to the business layer, while simultaneously receiving simulation dynamic data returned by the business layer to complete 3D visualization). The business layer carries the simulation task management subsystem (i.e., the business layer is configured to receive the simulation operation commands, complete simulation task parsing, distribute scheduling and control commands to the service layer, and simultaneously summarize the model calculation and hardware interaction data returned by the service layer and send it back to the application layer). The service layer carries the model calculation and service subsystem and the semi-physical interface subsystem (i.e., the service layer is configured to respond to scheduling commands issued by the business logic layer, complete distributed simulation calculations, interface with real hardware to convert virtual and real data, send the calculation and hardware interaction results back to the business layer, and read and write model and stored procedure data from the data layer). The data layer carries the data resource management subsystem (i.e., the data layer is configured to provide unified data support for the application layer, business layer, and service layer).

[0017] This invention has at least the following beneficial effects: 1) Based on a B / S architecture, this invention simplifies deployment: The system adopts a B / S architecture design, eliminating the need for users to install any dedicated client software. Users can complete the entire process from scenario planning and simulation to performance evaluation through a standard web browser, greatly reducing the deployment, upgrade, and maintenance costs of the system, and enabling cross-platform and cross-regional access and collaboration; 2) Introducing a "service layer" and a containerized model, this invention constructs a highly cohesive, loosely coupled, and flexible architecture: Traditional simulation systems are either tightly coupled (e.g., STK plugins) or integrated through heavy middleware (e.g., HLA / RTI), resulting in rigid model expansion and resource scheduling. This invention explicitly designs an independent service layer in its architecture and encapsulates the simulation model in the form of containerized microservices. The model communicates and schedules through a lightweight simulation middleware. This structure gives the system extremely high flexibility: new models can be quickly integrated like "Lego bricks"; computing resources can be dynamically scaled according to the load; each model can be independently developed, tested, and upgraded, significantly improving the system's scalability, maintainability, and resource utilization efficiency; 3) This invention realizes interactive process simulation that supports "human-in-the-loop": unlike the static batch analysis of tools such as STK, this system is based on distributed interactive simulation technology, allowing users to intervene in real time during the simulation process. For example, in satellite reconnaissance simulation, users can command the satellite to change the observation target or adjust the sensor mode at any time, and the system responds instantly and affects the subsequent simulation results. This function transforms the simulation from a "result verification" tool into a "process exploration" and "decision support" platform. The value of the platform is greatly enhanced; 4) This invention provides a standardized semi-physical interface, breaking down the barriers between digital simulation and physical testing. Through the semi-physical interface subsystem, this invention provides a standardized channel connecting the virtual and the real. Its core functions include: Hardware-in-the-loop testing: It can support the direct deployment of control algorithm models in the simulation environment to run on real satellites, using simulation data streams to stimulate real hardware for high-confidence testing; Digital escort and data verification: It can receive telemetry data from satellites in orbit in real time, drive the "virtual satellite" in the digital world to run synchronously, and realize anomaly reproduction, performance prediction and status comparison; This function extends the application scope of simulation from the design stage to the testing and operation and maintenance stage, realizing data closure throughout the entire product life cycle. Attached Figure Description

[0018] To further illustrate the above and other advantages and features of the various embodiments of the present invention, a more specific description of the embodiments of the invention will be presented with reference to the accompanying drawings. It is to be understood that these drawings depict only typical embodiments of the invention and are therefore not intended to limit its scope. In the drawings, identical or corresponding parts will be indicated by identical or similar reference numerals for clarity.

[0019] Figure 1A schematic diagram of the overall architecture of a distributed interactive spacecraft simulation system in some embodiments of the present invention is shown; Figure 2 A schematic diagram of the composition of a distributed interactive spacecraft simulation system in some embodiments of the present invention is shown; Figure 3 The diagram illustrates the information flow design of a distributed interactive spacecraft simulation system in some embodiments of the present invention. Figure 4 A schematic diagram of the workflow of a distributed interactive spacecraft simulation system in some embodiments of the present invention is shown. Detailed Implementation

[0020] It should be noted that the components in the accompanying drawings may be shown exaggerated for illustrative purposes and may not be to scale.

[0021] In this invention, the various embodiments are merely intended to illustrate the solutions of the invention and should not be construed as limiting.

[0022] In this invention, unless otherwise specified, the quantifiers “a” and “one” do not exclude scenarios involving multiple elements.

[0023] It should also be noted that, in the embodiments of the present invention, only a portion of the parts or components may be shown for clarity and simplicity. However, those skilled in the art will understand that, under the teachings of the present invention, the required parts or components can be added as needed for specific scenarios.

[0024] It should also be noted that within the scope of this invention, the terms "same", "equal", and "equal to" do not mean that the two values ​​are absolutely equal, but allow for a certain reasonable error. In other words, the terms also cover "substantially the same", "substantially equal", and "substantially equal to".

[0025] It should also be noted that in the description of this invention, the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not explicitly or implicitly suggest that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0026] Furthermore, the embodiments of the present invention describe the process steps in a specific order. However, this is only for the convenience of distinguishing each step, and is not a limitation on the order of each step. In different embodiments of the present invention, the order of each step can be adjusted according to the process.

[0027] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0028] I. Overall Architecture of Distributed Interactive Spacecraft Simulation System The distributed interactive spacecraft simulation system provided in this embodiment of the invention, Figure 1 The diagram illustrates the overall architecture of a distributed interactive spacecraft simulation system. Its software architecture adopts a layered, decoupled design concept, consisting of, from top to bottom: application layer, business logic layer, service layer, and data layer. These layers communicate through standardized interfaces, collectively supporting the entire distributed interactive simulation process.

[0029] Application Layer: Serving as the sole interface between the system and the user, it adopts a B / S architecture. Users access the web visualization portal and scenario editing and management console through a standard web browser to complete all simulation operations.

[0030] Business Layer: As the control center of the system, this layer includes the simulation scenario engine, resource scheduler, and performance evaluation engine. This layer is responsible for parsing user intent, transforming simulation scenarios into executable task flows, scheduling lower-level service resources, and performing online and post-simulation performance analysis.

[0031] Service Layer: As the runtime core of distributed interactive simulation, it is key to achieving dynamic and collaborative simulation in this invention. It includes simulation middleware, model container services, and a semi-physical interface gateway component. The simulation middleware serves as the core coordination bus of this layer, responsible for the registration, discovery, message routing, and simulation time synchronization of all simulation service nodes. The model container service group consists of multiple containerized, autonomous domain simulation models (such as orbit, attitude, load, and environment models). Each model is an independent microservice that interacts through the middleware, enabling plug-and-play and elastic scaling of the models. The semi-physical interface gateway acts as a dedicated bridge service connecting the virtual simulation and the real physical world. It connects to the simulation middleware, converting simulation commands into real hardware protocols and converting hardware feedback data into simulation messages; it is a core component for realizing hardware-in-the-loop testing and digital flight tracking.

[0032] Data Layer: As the data foundation of the system, it provides unified data support for the upper layers. This includes a simulation database for storing structured data, a spacecraft model repository for storing model images and files, and real hardware interfaces representing actual satellite units or telemetry and control equipment. II. Composition of a Distributed Interactive Spacecraft Simulation System Figure 2 The diagram illustrates the composition of a distributed interactive spacecraft simulation system. Based on the aforementioned four-layer technical architecture, from a functional domain perspective, the system is specifically implemented by the following five collaborative subsystems: Visualization and Interaction Subsystem: Includes a Web 3D visualization portal, scenario editing and management console components, providing a unified browser human-computer interaction interface, including all front-end functions such as 3D scene display, scenario editing, simulation monitoring, and real-time intervention control.

[0033] The simulation task management subsystem includes a simulation scenario engine, a resource scheduler, and a performance evaluation engine, serving as the system's command and control center. It is responsible for scenario analysis and driving, scheduling of computing resources and model services, and comprehensive evaluation of simulation performance.

[0034] Model Computation and Service Subsystem: This includes simulation middleware and model container service group components. As the system's simulation execution engine, it uses the simulation middleware as a message bus to coordinate and schedule numerous autonomous model container services, specifically performing simulation calculations in areas such as orbit, attitude, load, and environment.

[0035] The semi-physical interface subsystem includes a semi-physical interface gateway and protocol adapter library components, responsible for connecting the virtual simulation with the real physical world. It enables bidirectional conversion and real-time communication of data protocols between simulation commands and real satellite units / hardware.

[0036] The data resource management subsystem includes a simulation database and a spacecraft model repository component. As the system's data foundation, it is responsible for the persistent storage of all data, including simulation scenarios, model parameters, process data, and evaluation reports, as well as the versioned storage and management of files such as model images and 3D models.

[0037] III. Components The components will be described in detail below.

[0038] 1. Web Visualization Portal: Implemented based on WebGL technology (such as the Cesium.js framework), it is used for high-precision rendering of 3D scenes such as spacecraft, space targets, orbits, and sensor fields of view, and to receive and present simulation dynamic data in real time.

[0039] 2. Scenario Editing and Management Console: Provides a graphical drag-and-drop interface for editing simulation scenarios (scenarios), configuring entity parameters, and performing control operations such as starting, pausing, and stopping simulation tasks.

[0040] 3. Simulation Scenario Engine: Responsible for parsing user-edited scenario files, converting them into internally executable event-sequence logic, and driving the entire simulation process.

[0041] 4. Resource Scheduler: Based on the desired requirements, it dynamically manages and schedules the model computing resources in the service layer to achieve optimal task allocation.

[0042] 5. Performance Evaluation Engine: Built-in indicator calculation model to perform real-time or post-event comprehensive performance analysis and evaluation of simulation process and result data, and generate quantitative reports.

[0043] 6. Simulation Middleware: The core coordination bus of the system, implemented based on high-performance message queues (such as RabbitMQ and Kafka). It is responsible for the registration and discovery of all simulation nodes, message routing, time synchronization, and event distribution, and is the core technology of distributed interactive simulation.

[0044] 7. Model Container Service Group: Consists of multiple containerized autonomous simulation model services. Each service encapsulates an independent domain-specific model (such as a high-precision orbital dynamics model, attitude control model, synthetic aperture radar payload model, space environment model, etc.) and interacts with the simulation middleware through a standard interface.

[0045] 8. Semi-physical Interface Gateway: A dedicated microservice that acts as a protocol conversion hub between the simulation world and the physical world. It connects to the simulation middleware, converting virtual instructions into real hardware protocols and converting hardware feedback data into messages that the simulation environment can understand.

[0046] 9. Protocol Adapter Library: Integrates drivers for various standard and custom physical layer communication protocols, such as CCSDS space link protocol and custom TCP / IP protocol, to ensure reliable connection with various real satellite units or test equipment.

[0047] 10. Simulation Core Database: A relational or time-series database is used to store structured scenario configurations, model parameters, simulation process snapshots, performance evaluation results, and other data.

[0048] 11. Model and File Repository: Utilizes object storage services to manage unstructured assets such as simulation model container images, 3D mesh files, geographic information textures, and satellite design documents. IV. Information Flow of Distributed Interactive Spacecraft Simulation System System information flow design, such as Figure 3 As shown.

[0049] The following is a description of each interface: 1. Scenario and Interaction Commands: Transmits user-edited simulation scenario configuration data (scenario), as well as real-time control commands (such as start, pause, parameter adjustment) issued during simulation execution. The interface types are HTTP RESTFUL API and WebSocket.

[0050] 2. Real-time Situation and Assessment: The dynamic entity states, key events, and real-time performance evaluation indicators generated by the simulation are pushed to the front end for visualization. The interface type is WebSocket.

[0051] 3. Scheduling Instructions and Events: Transmits the sequence of simulation events generated by scenario analysis, as well as control instructions for scheduling computational resources and allocating tasks to the model services. The interface types are HTTP RESTful API and gRPC.

[0052] 4. Model Status and Results: Feedback on intermediate states, final results, and health status of each simulation model during the calculation process, for upper-level monitoring and evaluation. The interface type is a message middleware topic.

[0053] 5. Virtual Control Commands: These convert control logic generated in the simulation environment (such as attitude maneuver commands and load switching commands) into a standardized command format that is sent to the real hardware. The interface type is internal message bus / gRPC.

[0054] 6. High-fidelity physical data: Real-world operational data, such as telemetry and sensor readings, collected from actual satellite units or test equipment, are converted into a standardized data format understandable by the simulation environment. The interface type is internal message bus / gRPC.

[0055] 7. Resource Retrieval / Replay Request: The frontend requests model files, scenario templates, and 3D model assets stored in the database, or submits replay queries for historical simulation data. The interface type is HTTP RESTful API.

[0056] 8. Evaluation Data Access: Stores structured data such as the comprehensive evaluation report and detailed indicators generated after the simulation, or allows querying historical evaluation results for comparative analysis. The interface type is a database access interface.

[0057] 9. Process Data Persistence: During simulation execution, key process snapshots, entity state change logs, interaction events, and other pipeline data are asynchronously stored in the database for post-analysis. The interface type is an asynchronous message queue, a batch database write interface.

[0058] 10. Model / Scenario / Historical Data: Responds to frontend requests, providing the initial data resources required for simulation, including model definitions, scenario configurations, and archived historical simulation datasets. The interface type is HTTP RESTful API / file download service.

[0059] 11. Model / Configuration Data: During system startup or task initialization, provide the management subsystem with the necessary simulation model metadata, algorithm parameters, and system runtime configuration information. The interface type is HTTP RESTful API / configuration file.

[0060] 12. Model Image and Initial Data: Before the model container starts, provide it with the necessary container image, initial input files, basic geospatial data, and other large binary files or datasets. The interface type is file.

[0061] V. Workflow of Distributed Interactive Spacecraft Simulation System To illustrate the implementation methods and technical effects of the present invention in more detail, this embodiment takes a typical mission scenario of "multi-satellite joint detection of space debris" as an example to explain the system's workflow in detail.

[0062] Figure 4 This diagram illustrates the workflow of a distributed interactive spacecraft simulation system, which includes the following three stages: Phase 1: Scenario Planning and Initialization 1. Scenario planning and task initialization Users log in to the system and access the scenario editing and management console through the web-based visual portal.

[0063] Users configure scene elements via a graphical drag-and-drop interface: setting up an optical surveillance satellite (equipped with a visible light sensor) and a radar surveillance satellite (equipped with a synthetic aperture radar), and importing a batch of historical orbital data files of space debris. The mission objective is set as "to jointly identify, track, and assess the collision risk of space debris in a designated area within the next 24 hours."

[0064] After configuration, the user clicks "Start Simulation". The scenario data is then sent to the simulation engine in the business logic layer via HTTP API.

[0065] 2. Simulation Analysis and Distributed Scheduling The simulation engine parses the scenario and generates the simulation timeline, event sequence, and resource requirements list.

[0066] The resource scheduler sends scheduling instructions to the simulation middleware of the service layer based on the list.

[0067] The simulation middleware then dynamically launches a set of containerized model services on the cloud platform, including: optical satellite orbit and attitude container, optical sensor simulation container, radar satellite orbit and attitude container, radar sensor simulation container, multiple space debris orbit evolution containers, and data fusion and collision risk assessment containers. After these containers are launched, they register with the middleware as autonomous nodes and subscribe to the data topics they are interested in (such as satellite positions and debris orbit data).

[0068] Phase Two: Distributed Interactive Simulation Core Loop 1. Distributed interactive simulation and deduction When the simulation begins, the simulation middleware acts as the time master, broadcasting "simulation step" events to all model containers in steps (e.g., 1 second) to drive global time synchronization.

[0069] The various model containers perform parallel computations: the orbit container calculates the new positions of the satellite and debris; the sensor container determines whether the target has entered the field of view based on the relative geometric relationship and generates simulated detection data (such as image point clouds and radar echoes); the fusion container receives all detection data, correlates and filters it, and outputs the fused trajectory of the debris and collision warning.

[0070] Throughout the simulation, all key state and outcome data were published to the simulation middleware by the model container and then pushed to the web visualization portal in real time, forming a dynamically updated 3D scene. Simultaneously, the performance evaluation engine subscribed to data in real time, calculating and updating metrics such as coverage and tracking accuracy.

[0071] 2. Real-time human intervention within the loop Users observing the simulation may discover that a high-value satellite may have a risky intersection with the predicted trajectory of a piece of debris. Users can inject an emergency "avoidance maneuver" command into the satellite's attitude control container through the portal.

[0072] The instructions are translated by the business logic layer and then issued through the simulation middleware. Upon receiving the instructions, the corresponding model container adjusts its dynamic model. The satellite begins maneuvering, and the subsequent collision risk calculations are dynamically updated accordingly. This fully demonstrates the system's interactive process simulation capabilities.

[0073] 3. High-fidelity verification of semi-physical interface (optional) For high-confidence verification of radar signal processing algorithms, the semi-physical interface function can be enabled. The system deploys the radar signal processing model from the container to the actual signal processing board through the semi-physical interface gateway.

[0074] In subsequent simulations, the raw data generated by the radar echo generation model is converted into board communication protocol via a gateway and sent to the actual board. The results processed by the board are then returned to the simulation environment to participate in subsequent fusion calculations. This process realizes "hardware-in-the-loop" hybrid simulation, which greatly improves the simulation fidelity of specific stages.

[0075] Phase Three: Termination, Evaluation, and Archiving 1. Simulation Termination, Evaluation, and Archiving The simulation ends automatically after a set time, or can be manually terminated by the user. The resource scheduler notifies all model containers to gracefully exit via middleware.

[0076] The performance evaluation engine integrates data from the entire process to generate a comprehensive evaluation report that includes indicators such as space debris identification rate, tracking stability, and early warning timeliness, and stores it in the simulation database.

[0077] All simulation process data, model status snapshots, and interactive operation logs are fully archived by the data resource management subsystem, allowing users to perform historical playback and review analysis at any time.

[0078] As can be seen from the above embodiments, the system of the present invention can complete a complete closed loop in a unified, convenient and open platform, from scenario design, multi-node dynamic collaborative simulation, human-in-the-loop decision intervention, to semi-physical high-fidelity verification and quantitative performance evaluation, which fully verifies its powerful capabilities and significant advantages in handling complex aerospace system simulation tasks.

[0079] While some embodiments of the present invention have been described in this application, those skilled in the art will understand that these embodiments are merely illustrative. Numerous variations, alternatives, and improvements will arise in those skilled in the art under the teachings of this invention without departing from its scope. The appended claims are intended to define the scope of the invention and thereby cover methods and structures within the scope of the claims themselves and their equivalents.

Claims

1. A distributed interactive spacecraft simulation system, characterized in that, include: The visualization and interaction subsystem is configured to provide a unified browser-based human-computer interaction interface, collect users' simulation operation commands and output them outward, and receive the returned simulation situation data to complete the three-dimensional visualization display. The simulation task management subsystem is configured to receive simulation operation instructions issued by the visualization interaction subsystem, complete scenario analysis and driving, scheduling of computing resources and model services, comprehensive evaluation of simulation performance, issue simulation execution instructions, forward hardware control instructions, and summarize lower-level computation and hardware interaction data before sending them back to the visualization interaction subsystem for display. The model computation and service subsystem is configured to receive the simulation execution instructions, schedule the model container service group, perform distributed simulation computation, send the computation results back to the simulation task management subsystem, and retrieve storage resources as needed. The semi-physical interface subsystem is configured to receive the hardware control commands, complete the bidirectional conversion of protocols between virtual simulation and real hardware, and send the actual hardware test data back to the simulation task management subsystem to participate in simulation calculations. as well as The data resource management subsystem is configured to provide storage and retrieval support for model, configuration, and simulation data for the visualization interaction subsystem, simulation task management subsystem, model calculation and service subsystem, and semi-physical interface subsystem.

2. The distributed interactive spacecraft simulation system according to claim 1, characterized in that, The visual interaction subsystem includes: A web-based 3D visualization portal, implemented using WebGL technology, is configured to render 3D scenes of spacecraft, space targets, orbits, and sensor fields of view, and to receive and present simulation dynamic data in real time; and The scenario editing and management console is configured to provide a graphical drag-and-drop interface for users to edit simulation scenarios, configure entity parameters, and execute real-time control commands for simulation tasks.

3. The distributed interactive spacecraft simulation system according to claim 1, characterized in that, The simulation task management subsystem includes: The simulation scenario engine is configured to parse user-edited scenario files, convert the scenario files into internally executable event-sequence logic, and drive the entire simulation process. A resource scheduler is configured to dynamically manage and schedule model computing resources in the model computing and service subsystem according to predetermined needs, thereby achieving task allocation; and The performance evaluation engine has a built-in indicator calculation model and is configured to perform real-time or post-event comprehensive performance analysis and evaluation of simulation process and result data, generating quantitative reports.

4. The distributed interactive spacecraft simulation system according to claim 1, characterized in that, The model calculation and service subsystem includes: The simulation middleware is configured to handle the registration and discovery, message routing, time synchronization, and event distribution of all simulation nodes; and The model container service group consists of multiple containerized autonomous simulation model services. Each autonomous simulation model service encapsulates an independent professional domain model and interacts with the simulation middleware through a standard interface.

5. The distributed interactive spacecraft simulation system according to claim 4, characterized in that, The specialized models include orbital dynamics models, attitude control models, synthetic aperture radar payload models, and space environment models.

6. The distributed interactive spacecraft simulation system according to claim 4, characterized in that, The semi-physical interface subsystem includes: A semi-physical interface gateway, acting as a protocol conversion hub between the simulation world and the physical world, is configured to connect to the simulation middleware, converting virtual instructions into real hardware protocols and converting hardware feedback data into messages understandable by the simulation environment; and Protocol adapter library, which integrates drivers for various standard and custom physical layer communication protocols, to ensure reliable connection with real satellite units or test equipment.

7. The distributed interactive spacecraft simulation system according to claim 1, characterized in that, The data resource management subsystem includes: The simulation database, employing a relational or time-series database, is configured to store structured scenario configurations, model parameters, simulation process snapshots, performance evaluation results, and more. The spacecraft model repository uses object storage services and is configured to manage simulation model container images, 3D mesh files, geographic textures, and satellite design documents.

8. The distributed interactive spacecraft simulation system according to claim 1, characterized in that, Also includes: Run the interactive interface, which is configured to enable instruction interaction and data linkage during simulation. The runtime interaction class interface includes: The scenario and interaction command interface is configured to transmit user-edited simulation scenario configuration data and real-time control commands during simulation operation between the visualization interaction subsystem and the simulation task management subsystem. The real-time situation and assessment interface is configured to push the simulation entity status, simulation events, and performance evaluation indicators from the simulation task management subsystem to the visualization interaction subsystem to complete the front-end visualization display. The scheduling instruction and event interface is configured to transmit simulation event sequences and computing resource scheduling control instructions to the model computing and service subsystem. The model status and result interface is configured to send back the intermediate state of the simulation model, the calculation results, and the service health status to the simulation task management subsystem. A virtual control command interface, configured to issue hardware control commands to the semi-physical interface subsystem, completing the conversion of simulation control logic to hardware standard command format; and The high-fidelity physical data interface is configured to transmit operational telemetry data collected by real satellite units and test equipment back to the simulation task management subsystem and complete the data format standardization conversion.

9. The distributed interactive spacecraft simulation system according to claim 8, characterized in that, Also includes: The data resource access interface is configured to implement system simulation resource loading, data persistence, and historical data reuse. The runtime interaction class interface includes: The resource retrieval / replay request interface is configured to initiate query and replay requests for model, scenario, and historical simulation data to the data resource management subsystem. An evaluation data access interface is configured to store and query performance evaluation reports and indicator details data into the data resource management subsystem. A process data persistence interface is configured to asynchronously store simulation process snapshots and operation logs into the simulation database of the data resource management subsystem. The model / scenario / historical data interface is configured to send the model, scenario, and archived simulation dataset required for simulation initialization to the visualization interaction subsystem and the simulation task management subsystem. A model / configuration data interface, configured for use during the system initialization phase, wherein the data resource management subsystem transmits model metadata, algorithm parameters, and system configuration information to the simulation task management subsystem; and The model image and initial data interface is configured to allow the data resource management subsystem to distribute the container image, initial input file, and geospatial basic dataset to the model computing and service subsystem before the model container is started.

10. The distributed interactive spacecraft simulation system according to claim 1, characterized in that, The system adopts a four-layer architecture, which consists of the application layer, business layer, service layer, and data layer from top to bottom. The application layer carries the visualization interaction subsystem; the business layer carries the simulation task management subsystem; the service layer carries the model calculation and service subsystem and the semi-physical interface subsystem; and the data layer carries the data resource management subsystem.

Images