Satellite-borne intelligent processing platform simulation verification system and method

Abstract

This invention discloses a simulation verification system and method based on a spaceborne intelligent processing platform, belonging to the field of aerospace spaceborne simulation verification technology. The method involves constructing a virtual framework for an onboard system that integrates orbital mechanics simulation modeling, a spaceborne computing unit model library, and a space physics environment simulator. The algorithm to be verified is imported, and virtual computing resources are dynamically allocated according to a planned resource consumption list, forming an algorithm execution sandbox. A collaborative simulation scheduler is used to synchronously drive the algorithm sandbox, orbital, and space environment time-series data. The algorithm is executed in a dynamic virtual scenario, and full-state snapshots are recorded, generating multi-dimensional simulation operation logs. After parsing the obtained simulation result dataset, it is compared with a preset benchmark in multiple dimensions, generating verification conclusions including discrepancies, consistency criteria, and resource usage compliance reports. This method enables time-series collaboration of multiple simulation modules, fully acquiring the algorithm's running status, making the verification results more closely reflect actual on-orbit conditions.

Description

Technical Field

[0001] This invention belongs to the field of aerospace spaceborne simulation and verification technology, specifically a simulation and verification system and method based on a spaceborne intelligent processing platform. Background Technology

[0002] Current simulation verification of spaceborne intelligent processing algorithms mostly employs separate ground-based simulation modules for testing. Orbital mechanics simulation, spaceborne computing unit simulation, and space physics environment simulation operate independently, failing to construct an integrated onboard system virtual simulation framework. Virtual computing resources use a fixed parameter allocation mode, unable to be dynamically adjusted based on the algorithm's expected resource consumption list, and the algorithm operation lacks an independent, isolated simulation sandbox. During verification, orbital position and attitude time-series data and space physics environment time-series data cannot be synchronously driven with the algorithm execution process, and the simulation scenario cannot construct a dynamic operating environment that closely matches the on-orbit state. The algorithm operation process only records some operating parameters, failing to fully capture full-state snapshots; the simulation log has a single dimension and cannot fully reflect the state changes throughout the algorithm's operation. Existing verification processes only perform simple comparisons of algorithm output results, without synchronously verifying indicators such as actual resource consumption and time delay, resulting in insufficient coordination and completeness of simulation data.

[0003] Existing verification methods cannot generate systematic verification conclusions, only achieving single-dimensional result verification and failing to output complete reports that include discrepancies, consistency criteria, and resource usage compliance. A unified virtual framework integrating orbital mechanics simulation modeling, onboard computing unit model libraries, and space physics environment simulators needs to be built. This framework should dynamically allocate virtual computing resources based on the algorithm's expected resource consumption, construct independent algorithm execution sandboxes, achieve synchronous and collaborative scheduling of multiple types of simulation data with the algorithm sandboxes, fully record the algorithm's operational status information and generate multi-dimensional simulation logs, and perform multi-dimensional comparative analysis of the simulation result datasets to form standardized algorithm verification conclusions. Summary of the Invention

[0004] This invention aims to solve at least one of the technical problems existing in the prior art;

[0005] Therefore, this invention proposes a simulation verification method based on a spaceborne intelligent processing platform, including:

[0006] Construct a virtual framework for an onboard system that includes orbital mechanics simulation modeling, an onboard computing unit model library, and a space physics environment simulator;

[0007] Based on the virtual framework of the on-board system, the on-board intelligent processing algorithm to be verified is imported, and an integrated package of the algorithm to be verified is generated.

[0008] Within the virtual framework of the on-board system, virtual computing resources are dynamically allocated to the on-board intelligent processing algorithm to be verified based on the expected resource consumption list, forming an algorithm execution sandbox;

[0009] The algorithm running sandbox, the orbit position and attitude time series data generated by the orbit mechanics simulation modeling, and the space physics environment time series data generated by the space physics environment simulator are synchronously injected into the preset co-simulation scheduler.

[0010] The algorithm runs in a sandbox driven by the co-simulation scheduler, which executes the algorithm in a dynamic virtual space scenario composed of the orbital position and attitude time series data and the space physical environment time series data. The scheduler also records a full-state snapshot of the algorithm running sandbox during the running process, forming a multi-dimensional simulation running log.

[0011] The multi-dimensional simulation operation log is parsed to extract a simulation result dataset containing algorithm output results, actual resource consumption sequences, and time delay sequences;

[0012] The simulation result dataset is compared and analyzed in multiple dimensions with a preset verification benchmark to generate an algorithm verification conclusion that includes discrepancies, consistency criteria, and a resource usage compliance report.

[0013] Furthermore, the construction of the onboard system virtual framework, which includes orbital mechanics simulation modeling, an onboard computing unit model library, and a space physics environment simulator, includes:

[0014] Establish orbital mechanics equations describing the laws of satellite orbital motion, and develop orbital mechanics simulation models based on these equations to calculate the satellite's position, velocity, and attitude at any given time in real time, based on initial orbital parameters and attitude control command parameters.

[0015] The performance parameters and power consumption models of various onboard processors and memory architectures were collected, and a configurable onboard computing unit model library containing timing constraints, computing throughput and energy consumption characteristics was established.

[0016] The spatial distribution and temporal variation of space particle radiation and space thermal environment are modeled to obtain environmental quantification parameters, and a space physics environment simulator is constructed accordingly.

[0017] The orbital mechanics simulation modeling, the onboard computing unit model library, and the space physics environment simulator are registered and synchronized under a unified simulation timeline, and encapsulated into the onboard system virtual framework.

[0018] Furthermore, based on the aforementioned onboard system virtual framework, the onboard intelligent processing algorithm to be verified is imported, generating an integrated package of the algorithm to be verified, including:

[0019] The algorithm integration package to be verified includes the algorithm logic, expected resource consumption list, and interaction interface definition;

[0020] Analyze the source code or binary file of the onboard intelligent processing algorithm to be verified, and extract the algorithm logic;

[0021] Analyze the computational operations, data flow, and storage requirements involved in the algorithm logic to estimate the expected resource consumption list on the reference satellite computing unit;

[0022] Identify the input / output ports and protocols for data exchange between the algorithm logic and external systems, and form the interaction interface definition;

[0023] The algorithm logic, expected resource consumption list, and interaction interface definition, along with the algorithm's metadata, are packaged and encapsulated into the algorithm integration package to be verified.

[0024] Furthermore, within the virtual framework of the onboard system, virtual computing resources are dynamically allocated to the onboard intelligent processing algorithm to be verified based on the expected resource consumption list, forming an algorithm execution sandbox, including:

[0025] Select a virtual processor model from the onboard computing unit model library that matches the computing type in the expected resource consumption list, and determine the number of virtual processor models based on the parallelism requirements of the computing tasks in the expected resource consumption list;

[0026] Virtual memory space is requested from the onboard computing unit model library, and the capacity of the virtual memory space is not less than the maximum storage requirement estimated in the expected resource consumption list;

[0027] The allocated virtual processor model and virtual memory space are bound to the algorithm logic in the algorithm integration package to be verified, and the simulation data input and output channels are configured according to the interaction interface definition to complete the construction of the algorithm running sandbox.

[0028] Furthermore, the algorithm running sandbox, the orbital position and attitude time series data generated by the orbital mechanics simulation modeling, and the space physics environment time series data generated by the space physics environment simulator are synchronously injected into a preset co-simulation scheduler, including:

[0029] A global simulation clock is established in the co-simulation scheduler, and the global simulation clock drives the running steps of all simulation components;

[0030] The operation of the orbital mechanics simulation model is synchronized with the global simulation clock, so that it outputs orbital position and attitude timing data corresponding to the current simulation time at each simulation step.

[0031] The operation of the space physics environment simulator is synchronized with the global simulation clock, so that it outputs space physics environment timing data corresponding to the current simulation time and orbital position at each simulation step.

[0032] The algorithm running sandbox is synchronized with the global simulation clock, and its data input channel is configured to receive the orbital position and attitude timing data and the space physical environment timing data at the current step size.

[0033] Furthermore, the algorithm is driven by the co-simulation scheduler to run in a sandbox, executing within a dynamic virtual space scenario composed of the orbital position and attitude time-series data and the spatial physical environment time-series data. A full-state snapshot of the algorithm running in the sandbox is recorded during the running process, including:

[0034] At each simulation step, the co-simulation scheduler sends the current orbital position and attitude time series data and the space physical environment time series data as input signals to the input channel of the algorithm running sandbox;

[0035] The algorithm is driven to run a sandbox to process the input signal and execute its internal algorithm logic to generate intermediate calculation states and final output results;

[0036] During the execution of the algorithm in the sandbox, the changes in its internal virtual processor utilization, virtual memory usage, computation latency, and all intermediate variables and output results are continuously collected to form the full state snapshot at each step.

[0037] The full-state snapshots of all steps throughout the entire simulation duration are assembled in chronological order to form the multi-dimensional simulation run log.

[0038] Furthermore, the step of parsing the multi-dimensional simulation operation log to extract a simulation result dataset containing algorithm output results, actual resource consumption sequences, and time delay sequences includes:

[0039] Scan the multi-dimensional simulation operation log, separate the data records related to the algorithm function output, and organize them into the algorithm output result sequence;

[0040] Scan the multi-dimensional simulation operation log, extract the time series of virtual processor utilization and virtual memory usage, and combine them into the actual resource consumption sequence.

[0041] Analyze the timestamp difference between the algorithm receiving the input signal and producing the output result in the multi-dimensional simulation operation log, and calculate and form the time delay sequence;

[0042] The algorithm output sequence, actual resource consumption sequence, and time delay sequence are aligned onto a unified simulation time axis to form the simulation result dataset.

[0043] Furthermore, the simulation result dataset is compared with a preset verification benchmark in a multi-dimensional manner, including:

[0044] Invoke a pre-stored verification benchmark, which includes the expected algorithm output, resource consumption threshold, and time delay requirement;

[0045] In terms of functionality, the algorithm output sequence in the simulation result dataset is compared point by point with the expected algorithm output in the verification benchmark to identify the differences in the results.

[0046] In terms of resources, the actual resource consumption sequence in the simulation result dataset is compared with the resource consumption threshold in the verification benchmark to determine whether the resource consumption exceeds the limit.

[0047] In the time dimension, the time delay sequence in the simulation result dataset is compared with the time delay requirement in the verification benchmark to evaluate whether the time performance meets the standard.

[0048] The comparison results from the comprehensive functional, resource, and time dimensions are used to form a list of differences and a preliminary judgment.

[0049] Furthermore, the algorithm verification conclusion for generating the report, which includes discrepancies, consistency criteria, and resource usage compliance, includes:

[0050] Based on the list of discrepancies, a root cause analysis is performed on each discrepancy, and the discrepancies are divided into acceptable error ranges or unacceptable algorithm defects.

[0051] Based on the preliminary judgment results of the functional dimension comparison, resource dimension comparison and time dimension evaluation, the predefined consistency criterion rules are applied to make an overall conclusion of passing, conditionally passing or failing the onboard intelligent processing algorithm to be verified.

[0052] The system summarizes detailed data comparing the actual resource consumption sequence with the resource consumption threshold, and generates a resource usage compliance report that quantitatively describes resource usage.

[0053] The overall conclusions, root cause analysis results, and resource usage compliance report are packaged into the final algorithm verification conclusions.

[0054] Furthermore, this method also includes a simulation verification system based on a spaceborne intelligent processing platform. The system includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of the simulation verification method based on the spaceborne intelligent processing platform described above.

[0055] Compared with the prior art, the beneficial effects of the present invention are:

[0056] A virtual framework for the onboard system, integrating orbital mechanics simulation modeling, an onboard computing unit model library, and a space physics environment simulator, can unify and integrate orbital simulation, computing unit simulation, and space physics environment simulation, enabling collaborative connection between various simulation modules. Virtual computing resources are dynamically allocated to onboard intelligent processing algorithms based on the expected resource consumption list, ensuring that virtual resource configuration matches the algorithm's operational needs and optimizing the resource supply mode for algorithm operation. The algorithm execution sandbox provides an independent operating environment for the algorithm, reducing interference between the algorithm and other modules within the framework, maintaining the independence of the algorithm execution environment, and allowing each simulation module to continuously provide corresponding simulation data for algorithm operation, ensuring that the components of the simulation environment are consistent with the actual onboard operating environment.

[0057] Synchronizing algorithm execution sandbox, orbital position and attitude timing data, and spatial physical environment timing data with the co-simulation scheduler enables timing synchronization between multi-source simulation data and algorithm execution, allowing the algorithm to execute stably in a dynamic virtual space scenario. Collecting and recording full-state snapshots of the algorithm execution sandbox completely preserves the state information of each stage of algorithm execution, forming a multi-dimensional simulation execution log. Parsing the logs extracts algorithm output results, actual resource consumption sequences, and time delay sequences, forming a complete simulation result dataset. Multi-dimensional comparison of the simulation result dataset with a preset verification benchmark clarifies the differences between the simulation data and the benchmark data, determines consistency criteria, and intuitively reflects resource consumption and time delay during algorithm execution. Finally, a verification conclusion is generated, including discrepancies, consistency criteria, and a resource usage compliance report, improving the presentation format and coverage of the verification results. Attached Figure Description

[0058] Figure 1 This is a flowchart illustrating the steps of the simulation verification method based on a spaceborne intelligent processing platform described in this invention.

[0059] Figure 2 Comparison chart of spaceborne computing unit model libraries;

[0060] Figure 3 A flowchart for generating the integration package of algorithms to be verified;

[0061] Figure 4Calculate the latency performance analysis graph for the algorithm;

[0062] Figure 5 This is a comparison chart based on resource dimensions. Detailed Implementation

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

[0064] See Figure 1 This invention provides a simulation verification method based on a spaceborne intelligent processing platform. The method includes: constructing a virtual framework for an onboard system that includes orbital mechanics simulation modeling, a spaceborne computing unit model library, and a space physics environment simulator. This framework provides the dynamic space scene and computing environment foundation required for algorithm execution. Based on the constructed virtual framework, the spaceborne intelligent processing algorithm to be verified is imported. By parsing its code and structure, an integrated package of the algorithm to be verified, including algorithm logic, expected resource consumption list, and interaction interface definitions, is generated. Subsequently, within the virtual framework, virtual computing resources are dynamically allocated to the onboard intelligent processing algorithm to be verified according to the expected resource consumption list, forming an algorithm execution sandbox. Next, the algorithm execution sandbox, the orbital position and attitude time-series data generated by the orbital mechanics simulation modeling, and the space physics environment time-series data generated by the space physics environment simulator are synchronously injected into a preset co-simulation scheduler. The co-simulation scheduler drives the algorithm execution sandbox, enabling it to execute in a dynamic virtual space scene composed of orbital position and attitude time-series data and space physics environment time-series data. A full-state snapshot of the algorithm execution sandbox during operation is recorded, forming a multi-dimensional simulation operation log. Next, the multi-dimensional simulation logs are analyzed to extract a simulation result dataset containing algorithm outputs, actual resource consumption sequences, and time delay sequences. Finally, the simulation result dataset is compared with a preset verification benchmark in multiple dimensions to generate algorithm verification conclusions that include discrepancies, consistency criteria, and resource usage compliance reports.

[0065] In one embodiment of the present invention, a virtual framework for an onboard system is constructed, comprising orbital mechanics simulation modeling, an onboard computing unit model library, and a space physics environment simulator. The process involves: establishing orbital mechanics equations describing the satellite's orbital motion; developing orbital mechanics simulation modeling based on these equations to calculate the satellite's position, velocity, and attitude at any given time using initial orbital parameters and attitude control command parameters; collecting performance parameters and power consumption models of various onboard processors and memory architectures to establish a configurable onboard computing unit model library that includes timing constraints, computational throughput, and energy consumption characteristics; modeling the spatial distribution and temporal variations of space particle radiation and the space thermal environment to obtain quantified environmental parameters, and constructing a space physics environment simulator accordingly; and encapsulating the orbital mechanics simulation modeling, the onboard computing unit model library, and the space physics environment simulator under a unified simulation timeline through interface registration and synchronization signal agreements, thus forming the virtual framework for the onboard system.

[0066] In practical implementation, a virtual framework for the onboard system is constructed, comprising orbital mechanics simulation modeling, an onboard computing unit model library, and a space physics environment simulator. This process involves the independent development and final integration of multiple subsystems. Establishing orbital mechanics equations describing the satellite's orbital motion is the foundation for orbital mechanics simulation modeling development. These equations include a set of differential equations relating Kepler orbital elements to time, used to accurately describe the satellite's motion under the influence of the central gravitational body and other perturbations. Based on these orbital mechanics equations, orbital mechanics simulation modeling is developed to calculate the satellite's position, velocity, and attitude at any given time in real time, using initial orbital parameters and attitude control command parameters. The inputs to the orbital mechanics simulation modeling are the satellite's initial orbital parameters, attitude control command parameters, and simulation time. The outputs are the orbital position, velocity vector, and the satellite's attitude quaternions or Euler angles in inertial space at the corresponding time. Collecting performance parameters and power consumption models of various onboard processors and memory architectures is a prerequisite for building an accurate model library. These processors can include ARM Cortex-R series, RISC-V processors, or various aerospace-grade FPGAs. Performance parameters cover instruction set architecture, clock frequency range, cache size, and number of computing cores. Power consumption models describe the dynamic and static power consumption of the processor under different load rates. Memory architecture parameters involve storage type, access latency, bandwidth, and error correction mechanisms. A configurable onboard computing unit model library is established, incorporating timing constraints, computational throughput, and energy consumption characteristics. Configurability is reflected in allowing users to select processor type, number of cores, memory capacity, and bandwidth through configuration files, and set corresponding power consumption and performance constraint parameters. Modeling the spatial distribution and temporal variation of space particle radiation and the space thermal environment is the core of constructing a high-fidelity space environment simulation. The space particle radiation model injects high-energy proton and electron flux data based on radiation belt models or solar activity events. The space thermal environment simulator outputs a vector of quantitative parameters of the space thermal environment at the corresponding moment based on the input simulation time and the temperature of key satellite components. The orbital mechanics simulation modeling, the onboard computing unit model library, and the space physics environment simulator are registered and synchronized under a unified simulation timeline, and encapsulated into an onboard system virtual framework. The unified simulation timeline is managed by a high-precision global simulation clock. The interface registration defines the format, timing, and communication protocol for data exchange between the components. The synchronization signal agreement ensures that the orbital mechanics simulation modeling, the space physics environment simulator, and the subsequently connected algorithm running sandbox can advance the simulation process in a coordinated manner with the same step size. Finally, the encapsulated onboard system virtual framework provides a unified configuration and management interface, allowing users to load the algorithm to be verified and start the closed-loop simulation verification process.

[0067] See Figure 2This is a comparison chart of onboard computing unit model libraries, used to support the selection of virtual computing resources for onboard intelligent processing algorithms. ARM Cortex-R has the lowest clock speed, fewest cores, and lowest power consumption (5W), prioritizing reliability and real-time performance. It is suitable for low-complexity, high-real-time tasks such as attitude control and space management. RISC-V has a moderate clock speed, a medium number of cores (8 cores), the lowest power consumption (3W), and the best energy efficiency, suitable for energy-sensitive tasks such as lightweight AI inference and data preprocessing at the edge. FPGA has the most cores (16 cores), a relatively high clock speed, and the highest power consumption (10W), offering the strongest parallel computing capability. It is suitable for high-parallelism, high-throughput tasks such as target recognition, image compression, and signal processing. DSP has a relatively high clock speed, a medium number of cores, and relatively high power consumption (8W), offering outstanding numerical computation efficiency. It is suitable for signal processing tasks such as FFT transformation, filtering, and matrix operations.

[0068] In one embodiment of the present invention, based on the on-board system virtual framework, the on-board intelligent processing algorithm to be verified is imported, and an integrated package of the algorithm to be verified is generated. (See reference...) Figure 3 The algorithm integration package to be verified includes algorithm logic, a list of expected resource consumption, and interaction interface definitions. The source code or binary file of the onboard intelligent processing algorithm to be verified is parsed to extract the algorithm logic. The computational operations, data flow, and storage requirements involved in the algorithm logic are analyzed to estimate the expected resource consumption list on the reference onboard computing unit. The input / output ports and protocols for data exchange between the algorithm logic and external systems are identified, forming the interaction interface definitions. The algorithm logic, expected resource consumption list, and interaction interface definitions, along with the algorithm's metadata, are packaged and encapsulated into the algorithm integration package to be verified.

[0069] Within the onboard system's virtual framework, virtual computing resources are dynamically allocated to the onboard intelligent processing algorithms to be verified based on the expected resource consumption list, forming an algorithm execution sandbox. Virtual processor models matching the computation types in the expected resource consumption list are selected from the onboard computing unit model library, and the number of virtual processor models is determined based on the parallelism requirements of the computational tasks in the expected resource consumption list. Virtual memory space is requested from the onboard computing unit model library, with a capacity no less than the estimated maximum storage requirement in the expected resource consumption list. The allocated virtual processor models and virtual memory space are bound to the algorithm logic in the algorithm integration package to be verified, and the simulation data input / output channels are configured according to the interaction interface definition, completing the construction of the algorithm execution sandbox.

[0070] In practical implementation, based on the on-board system virtual framework, the on-board intelligent processing algorithm to be verified is imported and an integrated package of the algorithm to be verified is generated. The integrated package of the algorithm to be verified contains the algorithm logic, the expected resource consumption list, and the interaction interface definition. The source code or binary file of the on-board intelligent processing algorithm to be verified is parsed to extract the algorithm logic. For the source code written in C or Python, the parsing process constructs the abstract syntax tree of the algorithm through lexical analysis and syntax analysis. For the compiled binary file, the key control flow and data flow structure is restored through disassembly and intermediate representation analysis. In some embodiments, static code analysis tools are used to parse the source code or binary file of the on-board intelligent processing algorithm to be verified. The static code analysis tool traverses the abstract syntax tree or control flow graph to identify the function call relationships, loop structures, conditional branches, and core data processing operators in the algorithm. These identified elements together constitute the standardized representation of the algorithm logic. The algorithm logic involves analyzing computational operations, data flow, and storage requirements to estimate the expected resource consumption on the reference satellite computing unit. Quantification of computational operations includes the execution counts and data dimensions of operators such as statistical convolution, matrix multiplication, and nonlinear activation. Data flow analysis determines the lifecycle and data dependencies of intermediate variables. Storage requirement estimation is based on the peak memory usage of the data flow. The performance parameters of the reference satellite computing unit are used as a benchmark to convert the abstract computational workload of operators into specific processor cycle counts or floating-point operation counts. Optionally, the estimation of the expected resource consumption list can be based on statistical analysis of the number of loops and data size in the algorithm logic. For example, for an image processing algorithm containing nested loops, its total computational workload... A preliminary assessment can be made using the following formula:

[0071]

[0072] in: This indicates the number of computational layers or loop blocks in the algorithm. Indicates the first Number of operations per layer Indicates the first The baseline computational overhead required for a single operation at a layer, together with the memory access pattern analysis, constitutes a quantitative description of the computation and storage portions of the expected resource consumption list.

[0073] Identify the input and output ports and protocols for data exchange between the algorithm logic and external systems, forming an interaction interface definition. Input ports may correspond to sensor data input, orbital parameter injection, or command injection, while output ports correspond to processing results, status reports, or telemetry data transmission. The protocol specifies the data packet format, transmission rate, synchronization signal, and error handling mechanism. Package the algorithm logic, expected resource consumption list, and interaction interface definition, along with the algorithm's metadata, into a verification algorithm integration package. The metadata includes the algorithm name, version number, developer information, and dependency library descriptions. The encapsulation format uses an extensible markup language or a binary archive file to ensure that all components can be correctly identified and loaded by subsequent processes within the onboard system's virtual framework.

[0074] In practical implementation, within the onboard system's virtual framework, virtual computing resources are dynamically allocated to the onboard intelligent processing algorithms to be verified based on the expected resource consumption list, forming an algorithm execution sandbox. The dynamic allocation process begins by selecting virtual processor models from the onboard computing unit model library that match the computing types in the expected resource consumption list. For example, if the expected resource consumption list indicates that the algorithm involves a large number of parallel floating-point operations, a virtual digital signal processor model supporting vector instruction sets is selected from the onboard computing unit model library. If the algorithm is mainly logic control, a virtual microcontroller model may be selected. The number of virtual processor models is determined based on the parallelism requirements of the computing tasks in the expected resource consumption list. The parallelism requirements are determined by the number of task threads or data channels that can be executed in parallel in the algorithm logic. In some embodiments, determining the number of virtual processor models based on the parallelism requirements of the computing tasks in the expected resource consumption list is accomplished through a resource mapping module. The resource mapping module parses the description of the task parallelism graph or data parallelism dimension in the expected resource consumption list and instantiates a corresponding virtual processor model for each independent parallel execution unit. These virtual processor models communicate with each other through a virtual interconnect architecture. Virtual memory space is requested from the onboard computing unit model library. The capacity of the virtual memory space is not less than the maximum storage requirement estimated in the expected resource consumption list. The request operation submits a request containing capacity, access bandwidth, and latency requirements to the memory management unit of the onboard computing unit model library. The memory management unit of the onboard computing unit model library allocates a contiguous virtual address space and returns an access handle. It can be understood that the capacity configuration of the virtual memory space needs to reserve a certain margin to cope with the uncertainty of dynamic memory allocation during algorithm operation. This margin can be set as a fixed percentage based on the algorithm type or historical running data. The allocated virtual processor model and virtual memory space are bound to the algorithm logic in the algorithm integration package to be verified, and the simulation data input and output channels are configured according to the interaction interface definition to complete the construction of the algorithm running sandbox. The binding process includes loading the code segment and data segment of the algorithm logic into the allocated virtual memory space, pointing the instruction pointer of the virtual processor model to the entry address of the algorithm logic, and creating data queues or message ports for connection with orbital mechanics simulation modeling, space physics environment simulator, and other virtual components according to the interaction interface definition. It can be understood that the completed algorithm running sandbox is a closed entity with independent computing and memory space in the simulation environment, which can be driven and executed by the co-simulation scheduler.

[0075] The orbital position and attitude timing data generated by the algorithm running sandbox and the orbital mechanics simulation modeling, as well as the space physics environment timing data generated by the space physics environment simulator, are synchronously injected into a preset co-simulation scheduler. A global simulation clock is established in the co-simulation scheduler, driving the running steps of all simulation components. The orbital mechanics simulation modeling is synchronized with the global simulation clock, so that it outputs orbital position and attitude timing data corresponding to the current simulation time at each simulation step. The space physics environment simulator is synchronized with the global simulation clock, so that it outputs space physics environment timing data corresponding to the current simulation time and orbital position at each simulation step. The algorithm running sandbox is synchronized with the global simulation clock, and its data input channel is configured to receive the orbital position and attitude timing data and the space physics environment timing data for the current step.

[0076] In specific implementation, the orbital position and attitude timing data generated by the algorithm running sandbox and the orbital mechanics simulation modeling, as well as the space physics environment timing data generated by the space physics environment simulator, are synchronously injected into a preset co-simulation scheduler. This preset co-simulation scheduler is a central scheduling module whose core function is to maintain the time consistency and data synchronization of the simulation. A global simulation clock is established in the co-simulation scheduler. The global simulation clock is the sole time reference source for all events and calculation steps within the simulation system, and its time resolution is configurable. The global simulation clock drives the running steps of all simulation components. Running steps mean that each simulation component only executes calculations or state updates for the next time slice after receiving a step signal from the global simulation clock. In some embodiments, the global simulation clock drives the running steps of all simulation components through a callback mechanism. At the beginning of each simulation step, the co-simulation scheduler sends a step event containing the current simulation time value to all registered simulation components. The orbital mechanics simulation modeling, the space physics environment simulator, and the algorithm running sandbox execute the calculations for this step after receiving this event. The orbital mechanics simulation model is synchronized with the global simulation clock, enabling it to output orbital position and attitude timing data corresponding to the current simulation time at each simulation step. The synchronization process involves an integrated time listener within the orbital mechanics simulation model. This listener waits for step events from the co-simulation scheduler. Upon receiving an event, the orbital mechanics simulation model uses its integrated numerical integrator to advance the integration by one step based on the satellite state of the previous step, calculating the satellite position vector, velocity vector, and attitude quaternions at the end of the current step. This data is then output as the orbital position and attitude timing data. Optionally, the integrated numerical integrator can employ the Runge-Kutta method, with its integration step size either consistent with the global simulation clock's step size or using a smaller sub-step size, but ultimately outputting interpolated results aligned with the global simulation clock's step size. The formula for calculating the time of the orbital mechanics simulation model's output data is as follows:

[0077]

[0078] in: This indicates the simulation time corresponding to the current step size output data. Indicates the initial time of the simulation. This represents the total number of steps taken from the start of the simulation to the current position. This represents the fixed time interval of the global simulation clock. The orbital mechanics simulation model must ensure that the time interval is within the specified range. The data output at the end of each step precisely corresponds to... The satellite status at any given moment. The space physics environment simulator is synchronized with the global simulation clock, so that it outputs space physics environment timing data corresponding to the current simulation time and orbital position at each simulation step. The space physics environment simulator also listens to the stepping events of the global simulation clock. At each step, the space physics environment simulator receives the orbital position and attitude timing data output by the orbital mechanics simulation model for this step. Based on this position, it queries the geomagnetic field model, radiation belt model, and solar position model to calculate environmental parameters such as the geomagnetic field intensity vector, high-energy particle flux, and the direction and intensity of sunlight incidence at that position, and outputs these parameters as space physics environment timing data. Refer to Table 1, which shows a simplified simulation timing segment, illustrating the time alignment relationship between the global simulation clock, the orbital mechanics simulation model output, and the space physics environment simulator output.

[0079] Table 1: Correspondence between Simulation Timing and Data Output

[0080]

[0081] It is understood that the data in Table 1 is only for illustrating the alignment relationship, and the actual data values ​​are determined by the specific orbital parameters and environmental model. The algorithm running sandbox is synchronized with the global simulation clock, and its data input channel is configured to receive the orbital position and attitude timing data and the space physics environment timing data for the current step. The algorithm running sandbox also has an interface for communication with the co-simulation scheduler. At each global simulation clock step, after receiving a step event, the algorithm running sandbox reads the latest data generated by the orbital mechanics simulation model and the space physics environment simulator in this step from the data buffer of its input channel. These data together constitute the input signal of the algorithm running sandbox in the current step. In some embodiments, configuring its data input channel to receive data for the current step is achieved through shared memory or a message queue. After triggering the stepping of each component, the co-simulation scheduler immediately distributes the data packets output by the orbital mechanics simulation model and the space physics environment simulator to the input message queue corresponding to the algorithm running sandbox. The algorithm running sandbox reads data from this queue in the step callback function. Optionally, to simulate real-world data stream latency on the satellite, an optional transmission delay parameter can be set when configuring the input channel. This allows the algorithm execution sandbox to read historical data from the previous one or several steps after receiving a step event. It can be understood that through this synchronization mechanism, the orbital mechanics simulation modeling, the space physics environment simulator, and the algorithm execution sandbox are locked onto the same simulation timeline, ensuring strict temporal consistency between the dynamic virtual space scenario and algorithm execution, laying the foundation for the accuracy of subsequent recording and analysis.

[0082] In one embodiment of the present invention, a co-simulation scheduler drives an algorithm execution sandbox, which runs in a dynamic virtual space scenario composed of orbital position and attitude time-series data and spatial physical environment time-series data, and records a full-state snapshot of the algorithm execution sandbox during its operation. At each simulation step, the co-simulation scheduler sends the current orbital position and attitude time-series data and spatial physical environment time-series data as input signals to the input channel of the algorithm execution sandbox. The algorithm execution sandbox processes the input signals and runs its internal algorithm logic, generating intermediate computation states and final output results. During the execution of the algorithm execution sandbox, the changes in its internal virtual processor utilization, virtual memory usage, computational latency, and all intermediate variables and output results are continuously collected, forming a full-state snapshot for each step. The full-state snapshots of all steps throughout the entire simulation duration are assembled in chronological order to form a multi-dimensional simulation execution log. The multi-dimensional simulation execution log is parsed to extract a simulation result dataset containing algorithm output results, actual resource consumption sequences, and time delay sequences. Scan the multi-dimensional simulation logs to separate data records related to the algorithm's functional output and organize them into an algorithm output result sequence. Scan the multi-dimensional simulation logs again to extract the time series of virtual processor utilization and virtual memory usage, combining them into an actual resource consumption sequence. Analyze the timestamp difference between the algorithm receiving the input signal and producing the output result in the multi-dimensional simulation logs, calculating and forming a time delay sequence. Align the algorithm output result sequence, the actual resource consumption sequence, and the time delay sequence onto a unified simulation timeline to form a simulation result dataset.

[0083] In practical implementation, a co-simulation scheduler drives the algorithm execution sandbox, enabling it to run in a dynamic virtual space scenario composed of orbital position and attitude time-series data and spatial physical environment time-series data. The scheduler records a full-state snapshot of the algorithm execution sandbox during its operation; this process is the core loop of the simulation execution. At each simulation step, the co-simulation scheduler sends the current orbital position and attitude time-series data and spatial physical environment time-series data as input signals to the input channel of the algorithm execution sandbox. The input signal can be organized as a standardized data packet containing a timestamp, an array of orbital parameters, and an array of environmental parameters. The algorithm execution sandbox processes the input signals and runs its internal algorithmic logic, generating intermediate computation states and final output results. Upon receiving the input signals, the virtual processor model within the algorithm execution sandbox begins to execute calculations according to the loaded sequence of algorithmic logic instructions. The computation process involves a series of operations such as extracting features from the input data, performing numerical calculations, and making logical judgments. The final output result is, for example, a target identification marker, an image compressed data block, or an attitude control variable. During the algorithm execution sandbox operation, the internal virtual processor utilization, virtual memory usage, computational latency, and changes in all intermediate variables and output results are continuously collected, forming a full-state snapshot for each step. Virtual processor utilization is obtained by monitoring the proportion of the virtual processor model in a busy state within a unit simulation time. Virtual memory usage is obtained by querying the usage statistics of the virtual memory space allocated to the algorithm execution sandbox. Computational latency records the simulation time elapsed from the start of processing the current step's input to the generation of the final output result. The changes in intermediate variables and output results are obtained by inserting probes at key nodes of the algorithm logic or by periodically sampling using the debugging interface of the virtual processor model. In essence, a full-state snapshot is a complete, frozen record of the algorithm execution sandbox's internal computational state, resource usage, and output results at a specific simulation moment. The full-state snapshots of all steps throughout the entire simulation duration are assembled in chronological order to form a multi-dimensional simulation run log. The assembly process involves writing the full-state snapshot data collected at each step, including timestamps, resource metrics, intermediate variable values, and output results, into a structured log file or database in chronological order, using time as the primary key. This creates a record arranged chronologically, containing all observable states throughout the algorithm's execution. See Table 2 for a simplified data structure of a multi-dimensional simulation run log segment.

[0084] Table 2: Data Structure Table of Multi-Dimensional Simulation Run Log

[0085]

[0086] In some embodiments, forming a full-state snapshot at each step employs a combination of lightweight memory snapshots and incremental recording. Slow-changing states, such as virtual memory usage, are recorded periodically, while rapidly changing intermediate variables are recorded at each step, thus balancing log detail with recording overhead. Optionally, computation latency... It can be calculated precisely using a formula:

[0087]

[0088] in: This represents the timestamp at which the co-simulation scheduler sends a step-triggered signal to the algorithm execution sandbox. This indicates the timestamp when the algorithm runs in the sandbox and writes the final output to its output channel. This difference is recorded in the full-state snapshot of the corresponding step size.

[0089] In the specific implementation, the multi-dimensional simulation operation logs are parsed to extract a simulation result dataset containing algorithm output results, actual resource consumption sequences, and time delay sequences. This parsing operation is performed by a dedicated log analysis module. The multi-dimensional simulation operation logs are scanned to separate data records related to the algorithm's functional output, which are then organized into an algorithm output result sequence. The scanning process involves locating the fields identifying the final algorithm output in each log record according to a predefined log format, extracting and arranging these fields in chronological order to form an algorithm output result sequence indexed by simulation time. In some embodiments, the algorithm output results may be structured data objects. For example, in an object detection scenario, each output result contains the target bounding box coordinates, class confidence, and target ID; the algorithm output result sequence will contain a time series of all this information. The multi-dimensional simulation operation logs are also scanned to extract the time series of virtual processor utilization and virtual memory usage, which are then combined into an actual resource consumption sequence. The extraction operation involves reading the virtual processor utilization value and virtual memory usage value from each log record, forming a virtual processor utilization-time series and a virtual memory usage-time series, respectively. These two time series serve as the two dimensions of the actual resource consumption sequence. This study analyzes the timestamp difference between the algorithm's input signal reception and output result generation in the multi-dimensional simulation log, calculating and forming a time delay sequence. The analysis process involves reading the computation delay field recorded for each step in the log, or recalculating by parsing the input signal reception timestamp and output result generation timestamp, thus obtaining a time delay sequence synchronized with the simulation timeline. The time delay sequence reflects the actual time required for the algorithm to process each frame of input data and is a key indicator for evaluating the algorithm's real-time performance. The algorithm output result sequence, actual resource consumption sequence, and time delay sequence are aligned onto a unified simulation timeline to form a simulation result dataset. The alignment operation is based on the timestamp inherent in each data sequence, using interpolation or resampling to ensure that all sequences have corresponding data values ​​at the same, equally spaced simulation time points. The final simulation result dataset is a collection of multi-dimensional time series, with each row containing the same simulation time point, the algorithm output result at that moment, virtual processor utilization, virtual memory usage, and computation delay. Optionally, before constructing the simulation result dataset, the extracted original sequences can be preprocessed, for example, by using a moving average filter to smooth the actual resource consumption sequence to eliminate the influence of instantaneous noise.

[0090] See Figure 4This is a performance analysis chart of the algorithm's computational latency. The orange broken line with marked points shows the measured computational latency for each step; the red dashed line represents the average latency (16.1ms), serving as a performance benchmark. The latency values ​​oscillate significantly between 13ms and 20ms, without any prolonged stable periods. Multiple latency peaks (close to 20ms) and troughs (as low as around 13ms) reflect the computational load variations of the algorithm under different orbital attitude / environmental parameters. The latency values ​​fluctuate around 16.1ms for most time points, with some deviating from the benchmark; the reasons need to be analyzed in conjunction with simulation scenarios. The latency fluctuations stem from the real-time changes in orbital position / attitude time-series data and space physical environment time-series data. The algorithm needs to perform rapid calculations under different environmental parameters, leading to load fluctuations. Peak latency (≈20ms) may correspond to edge scenarios such as sudden changes in space radiation intensity or complex orbital attitude calculations.

[0091] In one embodiment of the present invention, a multi-dimensional comparative analysis is performed between the simulation result dataset and a preset verification benchmark. The pre-stored verification benchmark is invoked, and the benchmark includes expected algorithm output results, resource consumption thresholds, and time delay requirements. In the functional dimension, the sequence of algorithm output results in the simulation result dataset is compared point-by-point with the expected algorithm output results in the verification benchmark to identify discrepancies. In the resource dimension, the sequence of actual resource consumption in the simulation result dataset is compared with the resource consumption thresholds in the verification benchmark to determine whether resource consumption exceeds limits. In the time dimension, the sequence of time delays in the simulation result dataset is compared with the time delay requirements in the verification benchmark to evaluate whether time performance meets the standards. The comparison results from the functional, resource, and time dimensions are combined to form a list of discrepancies and a preliminary judgment. An algorithm verification conclusion is generated, including the discrepancies, consistency criteria, and a resource usage compliance report. Based on the list of discrepancies, root cause analysis is performed on each discrepancy, classifying them into acceptable error ranges or unacceptable algorithm defects. Based on the preliminary judgment results of functional dimension comparison, resource dimension comparison, and time dimension evaluation, predefined consistency criteria rules are applied to make an overall conclusion of pass, conditional pass, or fail for the onboard intelligent processing algorithm to be verified. Detailed data comparing the actual resource consumption sequence with resource consumption thresholds are summarized to generate a resource usage compliance report that quantitatively describes resource usage. The overall conclusion, root cause analysis results, and resource usage compliance report are packaged into the final algorithm verification conclusion.

[0092] In practice, the simulation result dataset is compared with a pre-defined verification benchmark in multiple dimensions. The benchmark is stored in a structured file, and its content is determined before the simulation begins. The pre-stored benchmark is invoked. The benchmark includes the expected algorithm output, resource consumption thresholds, and time delay requirements. The expected algorithm output corresponds to the standard output value or allowable error range that the algorithm should produce under a specific input scenario. The resource consumption threshold specifies the upper limit of virtual processor utilization, the upper limit of virtual memory usage, and the energy budget. The time delay requirement clarifies the maximum and average processing time allowed for the algorithm from input to output. In terms of functionality, the sequence of algorithm output results in the simulation result dataset is compared point-by-point with the expected algorithm output results in the verification benchmark. Differences are identified. This point-by-point comparison is performed at each identical sampling moment on the simulation timeline, comparing the actual output recorded in the simulation result dataset at that moment with the corresponding expected output in the verification benchmark. For numerical outputs, the absolute value of the difference is compared to see if it exceeds a pre-defined tolerance range. For classification or decision-making outputs, the two are compared to see if they are completely consistent. Any record point exceeding the tolerance or inconsistent with the expected output is marked as a result difference point. In the resource dimension, the actual resource consumption sequence in the simulation results dataset is compared with the resource consumption threshold in the validation benchmark to determine whether resource consumption exceeds the limit. The comparison operation involves comparing each data point in the virtual processor utilization time series with the processor utilization threshold specified in the validation benchmark, and comparing each data point in the virtual memory usage time series with the memory usage threshold specified in the validation benchmark, recording all data points exceeding the threshold and their magnitude and duration of exceedance. In the time dimension, the time delay sequence in the simulation results dataset is compared with the time delay requirements in the validation benchmark to assess whether time performance meets the standard. The assessment process involves calculating the maximum value, average value, or 95th percentile of the time delay sequence and comparing these statistics with the maximum allowable delay and average delay requirements specified in the validation benchmark to determine whether real-time constraints are met. Combining the comparison results from the functional, resource, and time dimensions, a list of discrepancies and a preliminary judgment are formed. The list of discrepancies is a structured list recording the simulation time, dimension, description of the discrepancy, and the value exceeding the limit for each discrepancy point. The preliminary judgment provides a binary "pass" or "fail" decision for each dimension.

[0093] Generate algorithm verification conclusions that include discrepancies, consistency criteria, and resource usage compliance reports. Based on the list of discrepancies, perform root cause analysis on each discrepancy, categorizing them into acceptable error ranges or unacceptable algorithmic defects. Root cause analysis involves examining the context in which the discrepancies occur. For example, in the functional dimension, a transient result discrepancy might stem from transient noise in the input data, while persistent result errors might point to algorithmic logic defects. In the resource dimension, occasional, small threshold exceedances might be attributed to operating system scheduling overhead and considered acceptable errors, while persistent exceedances indicate insufficient algorithmic resource estimation or resource leakage. Based on the preliminary judgment results from functional dimension comparison, resource dimension comparison, and time dimension evaluation, apply predefined consistency criteria rules to make an overall conclusion of pass, conditional pass, or fail for the onboard intelligent processing algorithm to be verified. The consistency criteria rules are defined in the form of logical conditions. In some embodiments, applying the predefined consistency criteria rules can employ a decision function, such as the overall conclusion. It can be determined by a function:

[0094]

[0095] in: This indicates the preliminary results of the functional dimension assessment. This indicates the preliminary results of the resource dimension assessment. This indicates the initial result of the time dimension assessment. The function represents the evaluation result of the acceptable set of differences. The specific logic is defined by the consistency criterion rules; for example, the rules might stipulate "if and only if..." , and When, the conclusion is passed; if If the difference is not within acceptable limits, the conclusion is "not passed"; otherwise, if all differences are found to be within acceptable limits after analysis, the conclusion is "conditionally passed". Detailed data comparing the actual resource consumption sequence with the resource consumption threshold is compiled to generate a resource usage compliance report that quantitatively describes resource usage. The report includes a graph of virtual processor utilization over time and its comparison with the threshold, a graph of virtual memory usage over time and its comparison with the threshold, a statistical summary of resource overrun events, and an average power consumption estimate. Optionally, the resource usage compliance report can further calculate the safety margin of resource usage, for example, using "(threshold - actual..." The "peak value / threshold" method is used to quantify the remaining processor and memory resources. It can be understood that the resource usage compliance report provides a precise profile of the algorithm's resource consumption characteristics in the simulated environment. The overall conclusions, root cause analysis results, and resource usage compliance report are packaged into the final algorithm verification conclusion. The packaging format can be a technical document containing standardized sections or a structured data file. The algorithm verification conclusion, as the final output of the simulation verification process, is used to guide iterative optimization of the algorithm or satellite deployment decisions. In some embodiments, the final algorithm verification conclusion also includes detailed data on a list of discrepancies to facilitate targeted investigation and modification by algorithm developers.

[0096] See Figure 5 This is a resource dimension comparison chart used to assess the resource usage compliance of the algorithm's runtime sandbox. CPU utilization fluctuates between approximately 15% and 68%, consistently remaining below the 80% CPU threshold, indicating no risk of exceeding limits. It exhibits a cyclical fluctuation of "initially rising → then falling → then rising again," strongly correlated with changes in computational load under different track / environment scenarios. Two high load peaks occur around 100 seconds and 800 seconds, corresponding to complex computational scenarios. Memory utilization fluctuates between approximately 10% and 49%, consistently remaining below the 60% memory threshold. Resource usage is stable and controllable, gradually decreasing over time before slowly recovering, with no risk of sudden memory leaks or peak overflows. It reaches approximately 49% around 200 seconds, representing the highest memory load throughout the cycle. CPU and memory utilization are positively correlated in the early stages (0–300 seconds) and decoupled in the later stages (300–1000 seconds), reflecting the differences in resource requirements at different stages of the algorithm. Neither utilization reaches the preset threshold, indicating that the current virtual computing resource allocation scheme meets resource usage compliance requirements.

[0097] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A simulation verification method based on a spaceborne intelligent processing platform, characterized in that, The method includes: Construct a virtual framework for an onboard system that includes orbital mechanics simulation modeling, an onboard computing unit model library, and a space physics environment simulator; Based on the virtual framework of the on-board system, the on-board intelligent processing algorithm to be verified is imported, and an integrated package of the algorithm to be verified is generated. Within the virtual framework of the on-board system, virtual computing resources are dynamically allocated to the on-board intelligent processing algorithm to be verified based on the expected resource consumption list, forming an algorithm execution sandbox; The algorithm running sandbox, the orbital position and attitude time series data generated by the orbital mechanics simulation modeling, and the space physical environment time series data generated by the space physical environment simulator are synchronously injected into the preset co-simulation scheduler. The algorithm runs in a sandbox driven by the co-simulation scheduler, which executes the algorithm in a dynamic virtual space scenario composed of the orbital position and attitude time series data and the space physical environment time series data. The scheduler also records a full-state snapshot of the algorithm running sandbox during the running process, forming a multi-dimensional simulation running log. The multi-dimensional simulation operation log is parsed to extract a simulation result dataset containing algorithm output results, actual resource consumption sequences, and time delay sequences; The simulation result dataset is compared and analyzed in multiple dimensions with a preset verification benchmark to generate an algorithm verification conclusion that includes discrepancies, consistency criteria, and a resource usage compliance report.

2. The simulation verification method based on a spaceborne intelligent processing platform according to claim 1, characterized in that, The construction of the onboard system virtual framework, which includes orbital mechanics simulation modeling, onboard computing unit model library, and space physics environment simulator, includes: Establish orbital mechanics equations describing the laws of satellite orbital motion, and develop orbital mechanics simulation models based on these equations to calculate the satellite's position, velocity, and attitude at any given time in real time, based on initial orbital parameters and attitude control command parameters. The performance parameters and power consumption models of various onboard processors and memory architectures were collected, and a configurable onboard computing unit model library containing timing constraints, computing throughput and energy consumption characteristics was established. The spatial distribution and temporal variation of space particle radiation and space thermal environment are modeled to obtain environmental quantification parameters, and a space physics environment simulator is constructed accordingly. The orbital mechanics simulation modeling, the onboard computing unit model library, and the space physics environment simulator are registered and synchronized under a unified simulation timeline, and encapsulated into the onboard system virtual framework.

3. The simulation verification method based on a spaceborne intelligent processing platform according to claim 2, characterized in that, Based on the aforementioned onboard system virtual framework, the onboard intelligent processing algorithm to be verified is imported, and an integrated package of the algorithm to be verified is generated, including: The algorithm integration package to be verified includes the algorithm logic, expected resource consumption list, and interaction interface definition; Analyze the source code or binary file of the onboard intelligent processing algorithm to be verified, and extract the algorithm logic; Analyze the computational operations, data flow, and storage requirements involved in the algorithm logic to estimate the expected resource consumption list on the reference satellite computing unit; Identify the input / output ports and protocols for data exchange between the algorithm logic and external systems, and form the interaction interface definition; The algorithm logic, expected resource consumption list, and interaction interface definition, along with the algorithm's metadata, are packaged and encapsulated into the algorithm integration package to be verified.

4. The simulation verification method based on a spaceborne intelligent processing platform according to claim 3, characterized in that, Within the virtual framework of the on-board system, virtual computing resources are dynamically allocated to the on-board intelligent processing algorithm to be verified based on the expected resource consumption list, forming an algorithm execution sandbox, including: Select a virtual processor model from the onboard computing unit model library that matches the computing type in the expected resource consumption list, and determine the number of virtual processor models based on the parallelism requirements of the computing tasks in the expected resource consumption list; Virtual memory space is requested from the onboard computing unit model library, and the capacity of the virtual memory space is not less than the maximum storage requirement estimated in the expected resource consumption list; The allocated virtual processor model and virtual memory space are bound to the algorithm logic in the algorithm integration package to be verified, and the simulation data input and output channels are configured according to the interaction interface definition to complete the construction of the algorithm running sandbox.

5. The simulation verification method based on a spaceborne intelligent processing platform according to claim 4, characterized in that, The algorithm running sandbox, the orbital position and attitude time series data generated by the orbital mechanics simulation model, and the space physics environment time series data generated by the space physics environment simulator are synchronously injected into a preset co-simulation scheduler, including: A global simulation clock is established in the co-simulation scheduler, and the global simulation clock drives the running steps of all simulation components; The operation of the orbital mechanics simulation model is synchronized with the global simulation clock, so that it outputs orbital position and attitude timing data corresponding to the current simulation time at each simulation step. The operation of the space physics environment simulator is synchronized with the global simulation clock, so that it outputs space physics environment timing data corresponding to the current simulation time and orbital position at each simulation step. The algorithm running sandbox is synchronized with the global simulation clock, and its data input channel is configured to receive the orbital position and attitude timing data and the space physical environment timing data at the current step size.

6. The simulation verification method based on a spaceborne intelligent processing platform according to claim 5, characterized in that, The algorithm is driven by the co-simulation scheduler to run in a sandbox within a dynamic virtual space scenario composed of the orbital position and attitude time-series data and the space physical environment time-series data. A full-state snapshot of the algorithm running in the sandbox is recorded during the running process, including: At each simulation step, the co-simulation scheduler sends the current orbital position and attitude time series data and the space physical environment time series data as input signals to the input channel of the algorithm running sandbox; The algorithm is driven to run a sandbox to process the input signal and execute its internal algorithm logic to generate intermediate calculation states and final output results; During the execution of the algorithm in the sandbox, the changes in its internal virtual processor utilization, virtual memory usage, computation latency, and all intermediate variables and output results are continuously collected to form the full state snapshot at each step. The full-state snapshots of all steps throughout the entire simulation duration are assembled in chronological order to form the multi-dimensional simulation run log.

7. The simulation verification method based on a spaceborne intelligent processing platform according to claim 6, characterized in that, The process of parsing the multi-dimensional simulation logs to extract a simulation result dataset containing algorithm output results, actual resource consumption sequences, and time delay sequences includes: Scan the multi-dimensional simulation operation log, separate the data records related to the algorithm function output, and organize them into the algorithm output result sequence; Scan the multi-dimensional simulation operation log, extract the time series of virtual processor utilization and virtual memory usage, and combine them into the actual resource consumption sequence. Analyze the timestamp difference between the algorithm receiving the input signal and producing the output result in the multi-dimensional simulation operation log, and calculate and form the time delay sequence; The algorithm output sequence, actual resource consumption sequence, and time delay sequence are aligned onto a unified simulation time axis to form the simulation result dataset.

8. The simulation verification method based on a spaceborne intelligent processing platform according to claim 7, characterized in that, The simulation result dataset is compared with a preset verification benchmark in a multidimensional manner, including: Invoke a pre-stored verification benchmark, which includes the expected algorithm output, resource consumption threshold, and time delay requirement; In terms of functionality, the algorithm output sequence in the simulation result dataset is compared point by point with the expected algorithm output in the verification benchmark to identify the differences in the results. In terms of resources, the actual resource consumption sequence in the simulation result dataset is compared with the resource consumption threshold in the verification benchmark to determine whether the resource consumption exceeds the limit. In the time dimension, the time delay sequence in the simulation result dataset is compared with the time delay requirement in the verification benchmark to evaluate whether the time performance meets the standard. The comparison results from the comprehensive functional, resource, and time dimensions are used to form a list of differences and a preliminary judgment.

9. The simulation verification method based on a spaceborne intelligent processing platform according to claim 8, characterized in that, The algorithm verification conclusions for generating the report, which includes discrepancies, consistency criteria, and resource usage compliance, include: Based on the list of discrepancies, a root cause analysis is performed on each discrepancy, and the discrepancies are divided into acceptable error ranges or unacceptable algorithm defects. Based on the preliminary judgment results of the functional dimension comparison, resource dimension comparison and time dimension evaluation, the predefined consistency criterion rules are applied to make an overall conclusion of passing, conditionally passing or failing the onboard intelligent processing algorithm to be verified. The system summarizes detailed data comparing the actual resource consumption sequence with the resource consumption threshold, and generates a resource usage compliance report that quantitatively describes resource usage. The overall conclusions, root cause analysis results, and resource usage compliance report are packaged into the final algorithm verification conclusions.

10. A simulation verification system based on a spaceborne intelligent processing platform, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the simulation verification method based on the spaceborne intelligent processing platform as described in any one of claims 1 to 9.

Images