Satellite model management method and system based on cloud native, electronic equipment and medium

Abstract

The invention provides a satellite model management method and system based on cloud native, electronic equipment and a medium, and relates to the technical field of cloud native, and the method comprises the steps: displaying a satellite model management main interface based on a cloud native architecture; in response to a trigger instruction for the model editing control, displaying a model editing sub-interface to obtain a resource file and configuration parameters of the satellite model; displaying a model deployment sub-interface to perform dependency library clipping and binary compression processing on the model executable file according to the lightweight level and the container template file to generate a lightweight container mirror image, deploying the lightweight container mirror image to a satellite-borne environment and a cloud environment through an edge cloud cooperation engine, and starting a container instance; and in response to a trigger instruction for the model management control, displaying a model management sub-interface so as to display the configuration parameters and the running state of the satellite model and manage the satellite model. Through the lightweight container mirror image generation and edge cloud collaborative deployment technology, the satellite-borne resource utilization efficiency of the satellite model is effectively improved.

Description

Technical Field

[0001] This application relates to the field of cloud-native technologies, and in particular, to a satellite model management method, system, electronic device, and medium based on cloud-native. Background Art

[0002] With the continuous expansion of satellite applications, from earth observation to fields such as communication and navigation, the development and deployment of satellite models have become increasingly complex. In the prior art, traditional model management adopts a centralized architecture, relies on manual operations, and has a fixed data processing mode. This results in low management efficiency, being error-prone; unreasonable resource utilization and waste; limited data processing capabilities, and difficulty in coping with massive real-time data. Although existing cloud-native technologies have improved the automation level to a certain extent, there are still many deficiencies in satellite model management. For example, model updates require full upload, resulting in waste of communication resources; redundant dependencies occupy on-board storage; high hardware redundancy fault tolerance costs and inability to dynamically respond to radiation interference; lack of coordination between ground and on-board environments leads to poor real-time performance; and complex multi-version management is prone to compatibility problems. Summary of the Invention

[0003] This application provides a satellite model management method, system, electronic device, and medium based on cloud-native to solve one or more technical problems existing in the prior art, and at least provide a beneficial choice or create conditions.

[0004] On the one hand, this application provides a satellite model management method based on cloud-native, including the following steps: Display a satellite model management main interface based on a cloud-native architecture; wherein, the satellite model management main interface includes a model editing control, a model deployment control, and a model management control; In response to a trigger instruction for the model editing control, display a model editing sub-interface to obtain the resource files and configuration parameters of the satellite model. The resource files include model executable files, container template files, and deployment template files, and the configuration parameters include basic parameters and on-board parameters. The on-board parameters include a lightweight level and an anti-radiation standard; In response to a trigger instruction for the model deployment control, display a model deployment sub-interface to perform dependency library trimming and binary compression processing on the model executable file according to the lightweight level and the container template file, generate a lightweight container image of the satellite model, and deploy the lightweight container image to the on-board environment and cloud environment of the cloud-native architecture through an edge-cloud collaboration engine, and start a container instance, where the container instance is used to run the satellite model; In response to a trigger instruction for the model management control, display a model management sub-interface to display the configuration parameters and running status of the satellite model and manage the satellite model.

[0005] Further, the display of the main interface for satellite model management based on the cloud native architecture includes: Automatically generate a model editing interface, a model deployment interface, and a model management interface in the cloud native architecture. The model editing interface is used to trigger the model editing algorithm of the cloud native architecture, the model deployment interface triggers the model deployment algorithm of the cloud native architecture, and the model management interface is used to trigger the model management algorithm of the cloud native architecture; Create an initial page, and create a model editing control associated with the model editing interface, a model deployment control associated with the model deployment interface, and a model management control associated with the model management interface on the initial page to obtain the main interface for satellite model management; Display the main interface for satellite model management.

[0006] Further, the display of the model editing sub-interface in response to a trigger instruction for the model editing control includes: In response to a trigger instruction for the model editing control, pass a first parameter to the model editing algorithm of the cloud native architecture to determine the requirements for filling in resource files and configuration parameters; Construct and display the model editing sub-interface according to the requirements for filling in resource files and the requirements for filling in configuration parameters; According to the resource file filling rules, construct a resource file addition control in the model editing sub-interface, and in response to a trigger instruction for the resource file addition control, display a resource file addition window to obtain the resource file of the satellite model; According to the configuration parameter filling rules, construct a configuration parameter acquisition control in the model editing sub-interface, and in response to a trigger instruction for the configuration parameter acquisition control, display a configuration parameter acquisition window to obtain the configuration parameters of the satellite model.

[0007] Further, the configuration parameter acquisition window includes a basic parameter acquisition control; The display of the configuration parameter acquisition window to obtain the configuration parameters of the satellite model includes: In response to a trigger instruction for the basic parameter acquisition control, parse the data structure and input constraint conditions of the basic parameters according to the configuration parameter filling rules; Based on the data structure and input constraint conditions of the basic parameters, construct a basic parameter acquisition window; obtain the name, version number, type, development language, and task parameters of the satellite model as the basic parameters in the basic parameter acquisition window, and save them to the model configuration database of the cloud native architecture.

[0008] Further, the configuration parameter acquisition window includes an on-board parameter acquisition control; The display configuration parameter acquisition window for acquiring the configuration parameters of the satellite model further includes: In response to a trigger instruction for the on-board parameter acquisition control, parsing the data structure and input constraint conditions of the on-board parameters according to the configuration parameter filling rules; Based on the data structure and input constraint conditions of the on-board parameters, constructing an on-board parameter acquisition window; wherein, the on-board parameter acquisition window includes a lightweight level acquisition area, an anti-radiation standard acquisition area, and an on-board parameter saving control; Invoking a lightweight classification algorithm to generate a recommended level list according to the resource occupancy rate of the model executable file; Displaying the recommended level list and acquiring the lightweight level in the lightweight level acquisition area; the lightweight level is a weighted scoring level of the resource occupancy rate and calculation delay of the model executable file; Invoking a node status monitoring algorithm to generate a recommended anti-radiation standard value according to the node radiation tolerance value in the cloud-native architecture; displaying the recommended anti-radiation standard value in the anti-radiation standard acquisition area and acquiring the anti-radiation standard; the anti-radiation standard is used to allocate redundant nodes in the cloud-native architecture; In response to a trigger instruction for the on-board parameter saving control, saving the lightweight level and the anti-radiation standard to the model configuration database of the cloud-native architecture.

[0009] Further, in response to a trigger instruction for the model deployment control, displaying a model deployment sub-interface, including: In response to a trigger instruction for the model deployment control, passing a second parameter to the model deployment algorithm of the cloud-native architecture to determine the lightweight packaging requirement and the edge-cloud collaborative deployment requirement; Constructing and displaying the model deployment sub-interface according to the lightweight packaging requirement and the edge-cloud collaborative deployment requirement; According to the container template file and the lightweight level in the configuration parameters, constructing a lightweight packaging control in the model deployment sub-interface, and in response to a trigger instruction for the lightweight packaging control, invoking a containerization engine to perform dependency library trimming and binary compression processing on the model executable file to generate a lightweight container image of the satellite model; According to the deployment template file and the anti-radiation standard in the configuration parameters, constructing a deployment configuration control in the model deployment sub-interface, and in response to a trigger instruction for the deployment configuration control, invoking the node adapter of the edge-cloud collaborative engine to perform the following operations: screening the on-board nodes of the cloud-native architecture and allocating fault-tolerant resources based on the anti-radiation standard; deploying the lightweight container image to the on-board environment and the cloud environment of the cloud-native architecture, and starting a container instance to run the satellite model.

[0010] Further, in response to a trigger instruction for the model management control, a model management sub-interface is displayed, including: In response to a trigger instruction for the model management control, a third parameter is passed to the model management algorithm of the cloud-native architecture to determine the monitoring requirements for configuration parameters, the monitoring requirements for the running state, and the version management requirements; Based on the monitoring requirements for configuration parameters, the monitoring requirements for the running state, and the version management requirements, the model management sub-interface is constructed and displayed; According to the data structure of the configuration parameters, a parameter monitoring area is constructed in the model management sub-interface to display the configuration parameters of the satellite model; According to the real-time running data of the edge-cloud collaboration engine, a running state monitoring area is constructed in the model management sub-interface to display the running state of the satellite model; According to the historical version records of the resource files and configuration parameters of the satellite model, the version management algorithm of the cloud-native architecture is called to generate version switching rules and compatibility verification requirements; Based on the version switching rules, a version switching control is constructed in the model management sub-interface and associated with the multi-version configuration files in the model configuration database; In response to a trigger instruction for the version switching control, a version switching window is displayed to load the resource files and configuration parameters of the target version to complete the version switching of the satellite model.

[0011] On the other hand, the present application provides a satellite model management system based on cloud-native, including a main interface module, a model editing module, a model deployment module, and a model management module; The main interface module is used to display the main interface of the satellite model management based on the cloud-native architecture; wherein, the main interface of the satellite model management includes a model editing control, a model deployment control, and a model management control; The model editing module is used to, in response to a trigger instruction for the model editing control, display a model editing sub-interface to obtain the resource files and configuration parameters of the satellite model, the resource files including model executable files, container template files, and deployment template files, the configuration parameters including basic parameters and on-board parameters, and the on-board parameters including the lightweight level and the anti-radiation standard; The model deployment module is used to respond to a trigger instruction for the model deployment control, display a model deployment sub-interface, and perform dependency library trimming and binary compression processing on the model executable file according to the lightweight level and the container template file, generate a lightweight container image of the satellite model, and deploy the lightweight container image to the on-board environment and the cloud environment of the cloud-native architecture through the edge-cloud collaboration engine, and start a container instance, where the container instance is used to run the satellite model; The model management module is used to respond to a trigger instruction for the model management control, display a model management sub-interface, and display the configuration parameters and running status of the satellite model and manage the satellite model.

[0012] On the other hand, the present application provides an electronic device, including: a processor and a memory; the memory is used to store a program; when the program is executed by the processor, the processor implements the foregoing cloud-native-based satellite model management method.

[0013] On the other hand, the present application provides a computer-readable storage medium, in which a processor-executable program is stored, and the processor-executable program is used to implement the foregoing cloud-native-based satellite model management method when executed by the processor.

[0014] The beneficial effects of this application are as follows: First, it displays the main interface of satellite model management based on the cloud-native architecture. The main interface of satellite model management includes a model editing control, a model deployment control, and a model management control. In this way, various controls on the interface can be associated with satellite model management, that is, a visual interaction interface is provided. In response to a trigger instruction for the model editing control, it displays a model editing sub-interface to obtain the resource files and configuration parameters of the satellite model. The resource files include model executable files, container template files, and deployment template files. The configuration parameters include basic parameters and on-board parameters. The on-board parameters include the lightweight level and the anti-radiation standard. In this way, relevant information related to the satellite model can be obtained in a personalized manner. In response to a trigger instruction for the model deployment control, it displays a model deployment sub-interface to perform dependency library trimming and binary compression processing on the model executable file according to the lightweight level and the container template file, generate a lightweight container image of the satellite model, and deploy the lightweight container image to the on-board environment and cloud environment of the cloud-native architecture through the edge-cloud collaboration engine, and start the container instance. The container instance is used to run the satellite model. This is equivalent to using lightweight container generation technology and edge-cloud collaborative deployment technology to improve the utilization efficiency of relevant information of the satellite model, especially on-board resources. Finally, in response to a trigger instruction for the model management control, it displays a model management sub-interface to display the configuration parameters and running status of the satellite model and manage the satellite model, which is convenient for managing the satellite model. In summary, this application effectively improves the utilization efficiency of on-board resources of the satellite model, and enhances the reliability and flexibility of the satellite model through a visual interaction interface, lightweight container image generation, and edge-cloud collaborative deployment technology. This application also provides corresponding systems, electronic devices, and media. The beneficial effects of the systems, electronic devices, and media are similar to those of the method and will not be elaborated here.

[0015] Other features and advantages of this application will be described in the subsequent specification. And, partly, they will be obvious from the specification, or can be understood by implementing this application. The objectives and other advantages of this application can be realized and obtained through the structures specifically pointed out in the specification, claims, and drawings. Brief Description of the Drawings

[0016] The drawings are used to provide a further understanding of the technical solutions of the present invention, and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the technical solutions of the present invention, and do not constitute a limitation to the technical solutions of the present invention.

[0017] Figure 1 It is a flowchart of the method for satellite model management based on cloud-native provided by this application; Figure 2 It is a schematic diagram of the main interface of satellite model management provided by this application; Figure 3 It is a schematic diagram of the model editing sub-interface provided by this application; Figure 4 It is a schematic diagram of the model deployment sub-interface provided by this application; Figure 5 It is a schematic diagram of the model management sub-interface provided by this application; Figure 6 It is a schematic diagram of the basic parameter acquisition window provided by this application; Figure 7 It is a schematic diagram of the on-board parameter acquisition window provided by this application; Figure 8 It is a schematic diagram of the node management sub-interface provided by this application; Figure 9 It is a schematic diagram of the node viewing sub-interface provided by this application; Figure 10 It is a schematic diagram of the container instance viewing sub-interface provided by this application; Figure 11 It is a schematic diagram of the container instance log viewing sub-interface provided by this application; Figure 12 It is a structural diagram of the cloud-native based satellite model management system provided by this application; Figure 13 It is a structural diagram of the electronic device for cloud-native based satellite model management provided by this application. Detailed implementation manners

[0018] In order to make the purpose, technical solutions and advantages of this application clearer, the following further details this application in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not used to limit this application.

[0019] The following further illustrates this application in conjunction with the accompanying drawings of the specification and specific embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of this application.

[0020] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments. However, it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the technical field to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0022] In view of the deficiencies of the prior art, the embodiments of the present application provide a cloud-native-based satellite model management method, system, electronic device, and medium. Through a visual interaction interface, lightweight container generation, edge-cloud collaborative dynamic deployment, and radiation-resistant intelligent scheduling, the embodiments of the present application alleviate to a certain extent the core problems of resource waste, low reliability, and poor flexibility in traditional satellite model management. At the same time, the visual interaction interface and multi-version compatible management improve operation efficiency and system maintainability, providing a highly adaptable solution for complex space missions.

[0023] First, the cloud-native-based satellite model management method provided by the embodiments of the present application will be elaborated in detail with reference to the accompanying drawings.

[0024] The cloud-native-based satellite model management method proposed by the embodiments of the present application can be applied to a terminal, a server, or software running on a terminal or a server. The terminal can be a tablet computer, a notebook computer, a desktop computer, etc., but is not limited thereto. The server can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms.

[0025] Referring to Figures 1 to 5 , the implementation process of the cloud-native-based satellite model management method provided by the embodiments of the present application includes but is not limited to steps 101 to 104.

[0026] Step 101, display the main interface 100 of satellite model management based on the cloud-native architecture.

[0027] Among them, referring to Figure 2 , the main interface 100 of satellite model management includes a model editing control 101, a model deployment control 102, and a model management control 103. In step 101, the main interface 100 for satellite model management based on the cloud-native architecture is displayed. The main interface 100 for satellite model management integrates multiple functional modules, including a model editing control 101, a model deployment control 102, and a model management control 103. By triggering these controls, the corresponding functional modules in the cloud-native architecture can be started, thereby realizing the management of satellite models on the cloud-native architecture. By triggering these controls, users can conveniently perform operations such as creating, deploying, and managing satellite models. The model editing control 101 allows users to upload or select relevant resource files of the satellite model and set necessary configuration parameters. The model deployment control 102 provides a convenient way to deploy the edited model to the target environment. The model management control 103 helps users monitor and adjust the status and configuration of the deployed model.

[0028] In some embodiments of the present application, the cloud-native architecture is a modern application development and deployment method aimed at making full use of the advantages of the cloud computing environment to achieve high scalability, elasticity, and automated management of applications. It is based on a microservices architecture, which decomposes an application into a set of small, independent services, each of which can be independently deployed, scaled, and updated. These services usually run in containers (such as Docker) and are managed and scheduled through container orchestration tools (such as Kubernetes) to ensure the effective utilization of resources and the high availability of services. The cloud-native architecture also emphasizes continuous integration and continuous delivery (CI / CD). Through automated build, test, and deployment processes, the software delivery cycle is accelerated, and human errors are reduced. In addition, this architecture supports functions such as dynamic configuration management, service discovery, and load balancing, further enhancing the flexibility and reliability of the system. For satellite algorithm management, the cloud-native architecture realizes the automated image building, deployment, dynamic replacement of external data sources, and version management of algorithms, significantly improving the efficiency, flexibility, and scalability of algorithm management.

[0029] In some embodiments of the present application, in a cloud-native architecture, the target environment for model deployment is a highly dynamic and automated runtime environment, typically designed based on containerization technology and microservices architecture. Specifically, the model is encapsulated in lightweight and portable containers, ensuring that it can run consistently on different computing nodes without being affected by differences in the underlying operating systems. These containers are managed through container orchestration tools to achieve automated deployment, scaling, and resource scheduling, ensuring high availability and elastic scaling capabilities. The target environment also includes support for dedicated hardware such as GPUs, enabling satellite algorithms that require high-performance computing to run efficiently. In addition, this environment supports dynamic configuration management and external data source integration, allowing the model to be flexibly adjusted according to different operating parameters and data sources. To ensure the stability and reliability of the system, real-time monitoring and logging functions are also provided to help operations and maintenance personnel promptly discover and resolve potential problems. The design of the entire environment aims to maximize the utilization of cloud computing resources, simplify the model deployment process, and provide powerful version control and continuous delivery capabilities to adapt to rapidly changing business requirements and technological evolution.

[0030] Step 102, in response to a trigger instruction for the model editing control 101, display a model editing sub-interface 200 to obtain the resource files and configuration parameters of the satellite model.

[0031] Among them, the resource files include model executable files, container template files, and deployment template files, and the configuration parameters include basic parameters and on-board parameters. The on-board parameters include the lightweight level and the anti-radiation standard.

[0032] In step 102, referring to Figure 3 , in response to a trigger instruction for the model editing control 101, the system will respond and display a specially designed model editing sub-interface 200. On this interface, the user can upload the resource files required for the satellite model, such as model executable files, container template files, and deployment template files. In addition, the user can also set a series of configuration parameters here, including basic parameters and on-board specific parameters, such as the lightweight level and the anti-radiation standard, etc. These parameters are crucial for ensuring that the satellite algorithm can run stably in the complex and changing space environment. Through this interface, the user can flexibly customize their own satellite model to meet different mission requirements.

[0033] It should be noted that the model executable file is the core part of the satellite model and contains the program code required for actual operation. It can be a compiled binary file (such as a program written in C or C++) or a script in an interpreted language (such as a Python script). These files are the basis for the specific tasks executed on the satellite.

[0034] In some embodiments of the present application, the container template file refers to a Dockerfile, which defines how to build a container image containing all dependencies and environment settings. Through the Dockerfile, a consistent and reliable running environment can be automatically created to ensure that the satellite model can work properly regardless of the deployment environment.

[0035] In some embodiments of the present application, the deployment template file is a Kubernetes YAML file used to define how to deploy and manage containerized applications in a cloud-native architecture. It includes definitions of resources such as Deployment, Service, ConfigMap, etc. These resources work together to achieve functions such as automated deployment, scaling, and service discovery of the model. Kubernetes is an open-source container orchestration platform for automating the deployment, scaling, and management of containerized applications, providing a powerful framework for running distributed systems to ensure high availability, scalability, and fault tolerance.

[0036] In some embodiments of the present application, the basic parameters are some general settings applicable to various types of satellite models. They may include information such as network configuration, storage requirements, log levels, etc., aiming to provide a basic operating environment for the model.

[0037] In some embodiments of the present application, considering the limitations of resources (such as computing power and storage space) in the space environment, the lightweight level determines the degree to which the model and its dependencies need to be optimized. The optimization process may involve measures such as trimming unnecessary libraries and compressing code to reduce the occupied space and improve execution efficiency.

[0038] In some embodiments of the present application, since radiation in space can damage electronic devices, corresponding anti-radiation standards need to be set according to the specific orbital position where the satellite will operate. This parameter guides the selection of hardware design and software fault tolerance mechanisms to ensure that the satellite model can operate stably and reliably in the harsh space environment.

[0039] Step 103: In response to a trigger instruction for the model deployment control 102, display the model deployment sub-interface 300 to perform dependency library trimming and binary compression processing on the model executable file according to the lightweight level and the container template file, generate a lightweight container image of the satellite model, and deploy the lightweight container image to the on-board environment and the cloud environment of the cloud-native architecture through the edge-cloud collaboration engine, and start the container instance.

[0040] Among them, the container instance is used to run the satellite model. In step 103, refer to Figure 4, In response to the trigger instruction for the model deployment control 102, the system will automatically enter the model deployment sub-interface 300. Here, based on the previously set lightweight level and the provided container template file, the system performs dependency library trimming and binary compression on the model executable file to generate a lightweight container image. This optimization not only reduces the storage space requirement but also improves the running efficiency in the spaceborne environment. After the image generation is completed, the system uses the edge-cloud collaboration engine to deploy these lightweight container images to the spaceborne environment and the cloud environment under the cloud-native architecture and starts the corresponding container instances. The purpose of this is to ensure that the satellite model can run under the best conditions while maintaining a high degree of flexibility and scalability.

[0041] In some embodiments of the present application, the lightweight level refers to the degree of optimization of the model and its running environment in the cloud-native architecture, aiming to reduce resource occupancy and improve deployment efficiency. Specifically, the lightweight level can be achieved in various ways, including but not limited to trimming unnecessary dependency libraries, compressing binary files, optimizing container images, etc. A higher lightweight level means less resource consumption and faster startup time, which is suitable for resource-constrained or scenarios that require quick response. By increasing the lightweight level, the computing cost can be significantly reduced, and the overall performance and scalability of the system can be improved.

[0042] In some embodiments of the present application, performing dependency library trimming and binary compression on the model executable file is one of the important means to achieve lightweight. Dependency library trimming refers to analyzing and removing the dependency libraries that are not required during the model running process, thereby reducing the volume of the finally generated executable file. Binary compression is to compress the executable file through a specific algorithm so that it occupies less space during storage and transmission. The combination of these two technologies can not only reduce the size of the container image but also speed up the file loading speed and the model startup time, especially suitable for edge computing environments with limited resources or application scenarios that require efficient deployment.

[0043] In some embodiments of the present application, the edge-cloud collaboration engine is a distributed computing framework aiming to achieve seamless collaboration and data exchange between edge devices and the cloud. It distributes computing tasks to the most suitable nodes (edge devices or cloud servers) for execution through an intelligent scheduling mechanism to optimize resource utilization and reduce latency. The edge-cloud collaboration engine usually has real-time data processing capabilities and can dynamically adjust the task distribution strategy to ensure the stability and efficiency of the system under high concurrency and complex computing requirements. In addition, the engine also supports data synchronization, cache management, and fault tolerance mechanisms, ensuring data consistency and service reliability in the edge computing environment.

[0044] In some embodiments of the present application, the on-board environment refers to the hardware and software infrastructure within a satellite for hosting and running various applications and services. Due to the extreme conditions of the space environment where the satellite is located (such as large temperature variations, strong radiation, etc.), the design of the on-board environment must consider high reliability and low power consumption characteristics. In terms of hardware, on-board devices usually adopt radiation-resistant materials and redundant designs to ensure normal operation under harsh conditions; in terms of software, highly optimized algorithms and efficient resource management mechanisms are required to adapt to limited computing resources and storage space. The on-board environment also supports remote update and maintenance functions, enabling the ground control center to upgrade the versions and repair faults of the applications on the satellite.

[0045] In some embodiments of the present application, the cloud environment refers to the virtualized computing resources and services provided based on a cloud computing platform, providing powerful computing, storage, and network support for application programs. The cloud environment usually consists of multiple data centers, each equipped with a high-performance server cluster, storage system, and network facilities, capable of dynamically allocating resources according to user needs. Through virtualization technology, the cloud environment can create isolated virtual machine or container instances, support the multi-tenant mode, and ensure the security and independence between different applications. In addition, the cloud environment provides rich development tools and automated operation and maintenance services, such as CI / CD pipelines, monitoring and alarm systems, etc., to help developers quickly build, test, and deploy applications, greatly improving development efficiency and system flexibility. The cloud environment also has good scalability and can flexibly increase or decrease resources according to business needs to meet the requirements of changing workloads.

[0046] Step 104: In response to a trigger instruction for the model management control 103, display the model management sub-interface 400 to display the configuration parameters and operating status of the satellite model and manage the satellite model.

[0047] In step 104, referring to Figure 5 , in response to a trigger instruction for the model management control 103, display the model management sub-interface 400, which provides a comprehensive view for users to view and manage all deployed satellite models. Users can not only monitor the configuration parameters and operating status of each model in real time but also perform various management operations as needed, such as updating configurations, restarting services, or deleting model instances that are no longer needed. This step greatly enhances the usability and controllability of the system, enabling users to more efficiently maintain and optimize their satellite models to ensure they are always in the optimal working state.

[0048] In some embodiments of the present application, in step 101, the implementation process of displaying the satellite model management main interface 100 based on the cloud-native architecture includes but is not limited to steps 201 to 203.

[0049] Step 201, automatically generate a model editing interface, a model deployment interface, and a model management interface in the cloud-native architecture.

[0050] Among them, the model editing interface is used to trigger the model editing algorithm of the cloud-native architecture, the model deployment interface triggers the model deployment algorithm of the cloud-native architecture, and the model management interface is used to trigger the model management algorithm of the cloud-native architecture.

[0051] In step 201, three key interfaces are generated in the cloud-native architecture in an automated manner: a model editing interface, a model deployment interface, and a model management interface. These interfaces are respectively used to trigger the corresponding algorithms, namely the model editing algorithm, the model deployment algorithm, and the model management algorithm, thus providing basic support for subsequent operations. This process ensures the modularity and scalability of the system, enabling each interface to operate independently and work together.

[0052] Step 202, create an initial page, and create a model editing control associated with the model editing interface, a model deployment control associated with the model deployment interface, and a model management control 103 associated with the model management interface on the initial page, so as to obtain the satellite model management main interface 100.

[0053] In step 202, the basic structure of the satellite model management main interface 100 is realized by creating an initial page and adding necessary user interaction controls thereto. Specifically, this step includes creating an editing control associated with the model editing interface, a deployment control associated with the model deployment interface, and a management control associated with the model management interface on the initial page. These controls provide an intuitive operation interface for users, enabling them to easily perform model editing, deployment, and management operations, improving the user experience and system usability.

[0054] Step 203, display the satellite model management main interface 100.

[0055] In step 203, the previously created satellite model management main interface 100 is presented to the user. This step realizes the conversion from the background logic to the front-end visualization, allowing the user to directly see and use the configured editing control, deployment control, and management control. By displaying this interface, the user can conveniently access and operate various functions, such as uploading resource files, setting configuration parameters, executing model deployment, and monitoring the model status, thus efficiently completing the management and maintenance tasks of the satellite model.

[0056] In some embodiments of the present application, referring to Figure 3 , in step 102, the implementation process of displaying the model editing sub-interface 200 in response to a trigger instruction for the model editing control 101 includes but is not limited to steps 301 to 304.

[0057] Step 301: In response to a trigger instruction for the model editing control 101, pass a first parameter to the model editing algorithm of the cloud-native architecture to determine the requirements for filling in resource files and configuration parameters.

[0058] In step 301, in response to a trigger instruction for the model editing control 101, the system passes necessary first parameters to the model editing algorithm in the cloud-native architecture. The first parameter is used to determine the requirements for filling in resource files and configuration parameters that the user needs when editing the satellite model, ensuring that subsequent operations can accurately meet the specific requirements of the user.

[0059] Step 302: Construct and display the model editing sub-interface 200 according to the requirements for filling in resource files and configuration parameters.

[0060] In step 302, according to the requirements for filling in resource files and configuration parameters obtained from step 301, the system dynamically constructs and displays a dedicated model editing sub-interface 200. This interface provides an intuitive operating environment for users, enabling them to conveniently upload or select the required resource files and set the corresponding configuration parameters, thus laying a foundation for the optimization and deployment of the model.

[0061] Step 303: Construct a resource file addition control 201 in the model editing sub-interface 200 according to the resource file filling rules, and in response to a trigger instruction for the resource file addition control 201, display a resource file addition window to obtain the resource files of the satellite model.

[0062] In step 303, create a resource file addition control 201 in the model editing sub-interface 200 according to the predefined resource file filling rules. In response to a trigger instruction for the resource file addition control 201, the system displays a resource file addition window, allowing users to upload the resource files of the satellite model, such as model executable files, container template files, and deployment template files, etc. This process simplifies the management process of resource files and improves the convenience and efficiency of user operations.

[0063] Step 304: Construct a configuration parameter acquisition control 202 in the model editing sub-interface 200 according to the configuration parameter filling rules, and in response to a trigger instruction for the configuration parameter acquisition control 202, display a configuration parameter acquisition window to obtain the configuration parameters of the satellite model.

[0064] In step 304, in order to fill in the rules according to the configuration parameters, a configuration parameter acquisition control 202 is generated in the model editing sub-interface 200. In response to a trigger instruction for the configuration parameter acquisition control 202, the system will pop up a configuration parameter acquisition window, enabling the user to input or select the configuration parameters of the satellite model, including basic parameters and on-board parameters (such as the lightweight level and anti-radiation standard). In this way, the user can precisely set the various configurations of the model to ensure its optimal performance and stability in the actual operating environment.

[0065] In some embodiments of the present application, the configuration parameter acquisition window includes a basic parameter acquisition control. In step 304, the implementation process of displaying the configuration parameter acquisition window to obtain the configuration parameters of the satellite model includes but is not limited to steps 401 to 403.

[0066] Step 401, in response to a trigger instruction for the basic parameter acquisition control, according to the configuration parameter filling rules, parse the data structure and input constraint conditions of the basic parameters.

[0067] In step 401, in response to a trigger instruction for the basic parameter acquisition control, the system will, according to the predefined configuration parameter filling rules, parse out the data structure and input constraint conditions required for the basic parameters. This information includes the data type, format requirements of the parameters, and any restrictive conditions that must be met (such as length restrictions, numerical ranges, etc.), ensuring that the data input by the user conforms to the expected specifications of the system.

[0068] Step 402, based on the data structure and input constraint conditions of the basic parameters, construct the basic parameter acquisition window 500.

[0069] In step 402, using the data structure and input constraint conditions of the basic parameters parsed in step 401, dynamically generate a user-friendly basic parameter acquisition window 500. This window will include various input fields and controls, allowing the user to input the basic parameters of the satellite model, such as name, version number, type, etc., in the specified format. In this way, the system can guide the user to complete the data entry accurately.

[0070] Step 403, obtain the name, version number, type, development language, and task parameters of the satellite model as basic parameters in the basic parameter acquisition window 500, and save them to the model configuration database of the cloud-native architecture.

[0071] In step 403, the window 500 is obtained through the basic parameters, enabling the user to input specific basic information of the satellite model, such as name, version number, type, development language, and task parameters, etc., and saving these data into the model configuration database in the cloud-native architecture. This step not only ensures the integrity and accuracy of the data but also provides the necessary basic data support for subsequent model deployment and management, enabling the system to quickly retrieve and use these configuration parameters when needed.

[0072] In some embodiments of the present application, the name of the satellite model is a string used to uniquely identify a satellite model. It is usually a concise and descriptive name that helps users quickly identify and distinguish different models. For example, "Orbit Prediction Model" or "Communication Signal Processing Model". The name helps to quickly find a specific model in the management interface and ensures that there is no confusion when multiple models coexist.

[0073] In some embodiments of the present application, the version number of the satellite model is a way to identify different iterations of the satellite model, usually using semantic version control (such as 1.0.0, 1.1.0). The version number not only reflects the development progress of the satellite model but also facilitates tracking the change history of the satellite model. This is particularly important for managing and maintaining multiple versions of the satellite model, especially when it is necessary to roll back to a certain stable version or compare the differences between different versions.

[0074] In some embodiments of the present application, the type of the satellite model is used to represent the specific category or use of the satellite model, such as data processing, image recognition, orbit calculation, etc. The type information helps to classify and retrieve the satellite models, enabling the system to quickly find the appropriate satellite model according to specific requirements. In addition, the type can also guide subsequent deployment and optimization strategies to ensure that the satellite model can run in an appropriate environment.

[0075] In some embodiments of the present application, the development language refers to the programming language used to write the satellite model, such as C++, Python, Java, etc. This information is crucial for determining the model's dependency libraries, running environment, and the choice of compiler or interpreter. Knowing the development language can help the operation and maintenance personnel correctly configure the running environment and ensure that the model can execute smoothly on the target platform.

[0076] In some embodiments of the present application, the task parameters are configuration options or input values related to the specific tasks of the satellite model, which determine the behavior of the model when performing specific tasks. For example, in the orbit prediction model, the task parameters may include the initial position, velocity vector, etc.; while in the communication signal processing model, it may involve the frequency range, signal strength threshold, etc. The task parameters allow users to flexibly adjust the model to adapt to different application scenarios, thereby maximizing its effectiveness.

[0077] In some embodiments of the present application, referring to Figure 6 , the basic parameter acquisition window 500 includes a name acquisition area 501, a version number acquisition area 502, a type acquisition control 503, a development language acquisition control 504, a task parameter acquisition control 505, and a basic parameter saving control 506; in the name acquisition area 501, the model name is acquired through a text input box; in the version number acquisition area 502, the model version number is acquired through a text input box; in response to a trigger instruction for the type acquisition control 503, a model type database of the cloud native architecture is called, an optional model type list is displayed in the type acquisition window, and the model type selected by the user is acquired; in response to a trigger instruction for the development language acquisition control 504, according to the set of development languages supported by the container template file, options are displayed in the development language acquisition window, and the model development language is acquired; in response to a trigger instruction for the task parameter acquisition control 505, the metadata of the model executable file is loaded, a parameter input form associated with the model task is generated in the task parameter acquisition window, and the model task parameters are acquired; in response to a trigger instruction for the basic parameter saving control 506, the model name, model version number, model type, model development language, and model task parameters are bound as structured data and saved to the model configuration database of the cloud native architecture.

[0078] In some embodiments of the present application, the configuration parameter acquisition window includes an on-orbit parameter acquisition control. In step 304, the implementation process of displaying the configuration parameter acquisition window to acquire the configuration parameters of the satellite model includes but is not limited to steps 501 to 507.

[0079] Step 501, in response to a trigger instruction for the on-orbit parameter acquisition control, according to the configuration parameter filling rules, parse the data structure and input constraint conditions of the on-orbit parameters.

[0080] In step 501, in response to a trigger instruction for the on-orbit parameter acquisition control, the system parses the data structure and input constraint conditions required for the on-orbit parameters according to the predefined configuration parameter filling rules. This information includes the data type, format requirements of the parameters, and any restrictive conditions that must be met (such as numerical range, specific unit, etc.), ensuring that the data input by the user conforms to the expected specifications of the system.

[0081] Step 502, based on the data structure and input constraint conditions of the on-orbit parameters, construct the on-orbit parameter acquisition window 600.

[0082] Among them, referring to Figure 7 , the on-orbit parameter acquisition window 600 includes a lightweight level acquisition area 601, an anti-radiation standard acquisition area 605, and an on-orbit parameter saving control 608.

[0083] In step 502, using the data structure of the on-board parameters parsed in step 501 and the input constraint conditions, a user-friendly on-board parameter acquisition window 600 is dynamically generated. This window includes a lightweight level acquisition area 601, an anti-radiation standard acquisition area 605, and an on-board parameter saving control 608, enabling users to conveniently input and adjust the on-board parameters of the satellite model.

[0084] Step 503, call the lightweight classification algorithm to generate a recommended level list 602 based on the resource occupancy rate of the model executable file.

[0085] In step 503, by calling the lightweight classification algorithm, analyze the resource occupancy of the model executable file and generate a series of recommended lightweight levels. These levels are based on the weighted score between the resource occupancy rate and the calculation latency, helping users select the most suitable optimization level for their needs, thus finding a balance between performance and resource usage.

[0086] In some embodiments of the present application, the goal of the lightweight classification algorithm is to generate a multi-level optimization recommendation scheme (such as level one to level five) based on the resource occupancy rate (including resources such as CPU, memory, and storage) and calculation latency of the satellite model, helping users balance performance and efficiency in an environment with limited on-board resources. Through quantitative scoring and level division, guide subsequent dependent library trimming and binary compression strategies to ensure that the generated container image achieves the best balance between lightweight and functional integrity.

[0087] Specifically, the input parameters of the lightweight classification algorithm include the resource occupancy rate and calculation latency of the model executable file. The resource occupancy rate includes CPU usage rate, memory occupancy rate, and external memory occupancy rate, etc. The calculation latency refers to the response time and processing time of the model when executing tasks. The output result of the lightweight classification algorithm is a recommended lightweight level list, and each level corresponds to a weighted score, reflecting the balance between the resource occupancy rate and the calculation latency. Users can select the most suitable lightweight level according to the recommended list. The weighted score Satisfies the following formula (1): (1); In formula (1), Represents the resource occupancy rate of the model executable file, Represents The corresponding weight parameter; Represents the calculation latency of the model executable file, Represents The corresponding weight parameter.

[0088] In some embodiments of the present application, the lightweight level list is specifically as follows: when the weighted score is less than or equal to 20%, the lightweight level is level one, and the optimization strategy adopted is the highest compression (UPX extreme mode) and trimming all non-core dependent libraries, such as only retaining the OpenCV core module; when the weighted score is greater than 20% and less than or equal to 40%, the lightweight level is level two, and the optimization strategy adopted is high compression (UPX balanced mode) and trimming some dependent libraries, such as removing the debug toolchain; when the weighted score is greater than 40% and less than or equal to 60%, the lightweight level is level three, and the optimization strategy adopted is moderate compression (ELF compression) and trimming optional dependent libraries, such as removing multi-language support; when the weighted score is greater than 60% and less than or equal to 80%, the lightweight level is level four, and the optimization strategy adopted is low compression (only removing redundant symbols) and retaining all dependent libraries; when the weighted score is greater than 80%, the lightweight level is level five, and the optimization strategy adopted is no compression and retaining the complete dependent libraries, which is applicable to high-performance nodes in the cloud.

[0089] It should be noted that the UPX tool is an open-source executable file packing tool that can compress executable files (such as.exe files for Windows or ELF files for Linux) to reduce the file size. The compression modes of UPX include the extreme mode and the balanced mode. Among them, the extreme mode provides the highest compression ratio, but may affect the file loading speed, while the balanced mode achieves a balance between the compression ratio and the file loading speed. ELF compression is a compression technology for Linux executable files. By erasing the last few bits of the floating-point value (i.e., setting them to zero), an XOR result with a large number of trailing zeros is obtained, thereby improving the compression efficiency. During the model lightweighting process, different compression modes and optimization strategies are selected according to the weighted score to minimize the model storage space and improve the running efficiency while ensuring the model performance.

[0090] In some embodiments of the present application, scene-adaptive recommended lightweight levels are supported. If the user selects on-orbit deployment, lightweight levels from level one to level three are preferentially recommended, focusing on resource savings; if the user selects cloud deployment, lightweight levels from level four to level five are recommended to ensure the model performance.

[0091] In some embodiments of the present application, users are supported to customize and adjust the lightweight level, a lightweight level slider control is provided, and manual adjustment of the lightweight level is allowed.

[0092] Step 504, display the recommended level list 602 and obtain the lightweight level in the lightweight level acquisition area 601.

[0093] Among them, the lightweight level is the weighted score level of the resource occupancy rate and the calculation delay of the model executable file.

[0094] In step 504, in the lightweight level acquisition area 601, the recommended level list 602 generated in step 503 is displayed, allowing the user to select a suitable lightweight level therefrom. The lightweight level reflects the weighted score between the resource occupancy rate and the calculation latency of the model executable file, and the user's selection will directly affect the performance of the model during actual operation.

[0095] In some embodiments of the present application, the lightweight level acquisition area 601 includes a lightweight level input box 603 to obtain the lightweight level input by the user.

[0096] In some embodiments of the present application, the lightweight level acquisition area 601 includes a one-key setting lightweight level control 604. In response to the trigger instruction for the one-key setting lightweight level control 604, the system automatically sets the lightweight level of the satellite model according to the recommended lightweight level of the satellite model.

[0097] Step 505, call the node status monitoring algorithm to generate a recommended anti-irradiation standard value according to the node irradiation tolerance value in the cloud-native architecture.

[0098] In step 505, by calling the node status monitoring algorithm, the irradiation tolerance capabilities of each node in the cloud-native architecture are evaluated, and recommended anti-irradiation standard values are generated. These standard values are used to guide how to allocate redundant nodes to ensure that the satellite model can operate stably and reliably in a high-radiation environment.

[0099] Step 506, display the recommended anti-irradiation standard value in the anti-irradiation standard acquisition area 605 and obtain the anti-irradiation standard.

[0100] Among them, the anti-irradiation standard is used to allocate redundant nodes in the cloud-native architecture.

[0101] In step 506, the recommended anti-irradiation standard value generated in step 505 is displayed in the anti-irradiation standard acquisition area 605, enabling the user to select the most suitable anti-irradiation standard. The anti-irradiation standard determines how to allocate redundant nodes in the space environment to cope with possible radiation damage and ensure the high availability and reliability of the system.

[0102] In some embodiments of the present application, the implementation process of evaluating the irradiation tolerance capabilities of each node in the cloud-native architecture by calling the node status monitoring algorithm and generating recommended anti-irradiation standard values includes but is not limited to the following steps.

[0103] First, call the node status monitoring algorithm to evaluate the radiation tolerance of each node in the cloud-native architecture. The data sources for node status monitoring include the radiation intensity, cumulative dose, and single-event upset frequency collected in real time by on-board radiation sensors (such as TID sensors and single-event effect monitors), the node hardware attributes (radiation-hardened level, redundancy design, processor type), as well as historical failure records and task load cycles. Combining environmental events (such as solar storm warnings) with the node health status, a multi-dimensional input data set is constructed to provide a basis for calculating the radiation protection standard. The evaluation process of the radiation tolerance of each node (i.e., the node health status) in the cloud-native architecture satisfies the following formula (2): (2); In formula (2), represents the radiation tolerance of node (ranging from 0 to 1); represents the maximum tolerable radiation dose of the node, which is determined by the node's hardware attributes; represents the current cumulative radiation dose; represents the single-event upset frequency; represents the preset soft error tolerance threshold.

[0104] Then, according to the radiation tolerance of each node, the redundancy level is dynamically divided. Specifically, when the radiation tolerance of node is , node is regarded as a high-risk node, and the recommended radiation protection standard value for node is N + 2, that is, 2 redundant copies are allocated for node (a total of 3 instances run the same task) to ensure task continuity in extreme radiation environments. For example, during a solar storm or when the cumulative radiation dose of the node approaches the hardware limit, two backups are allocated for the node to reduce the risk of single-point failure. When the radiation tolerance of node is , node is regarded as a medium-risk node, and the recommended radiation protection standard value for node is N + 1, that is, 1 redundant copy is allocated for node (2 instances run the same task) to balance resource occupancy and fault tolerance. For example, during a regular space mission, when the radiation intensity of the node fluctuates but does not exceed the threshold, one backup is allocated for the node to withstand single-node instantaneous failures. When the radiation tolerance of node is , node is regarded as a low-risk node, and no redundant copy needs to be allocated for node Allocation backup, that is, the recommended anti-radiation standard value is N, which maximally saves on-board resources. For example, when the node is within the safe radiation range and has a high historical stability, there is no need to allocate a backup for the node to optimize storage and computing power.

[0105] In some embodiments of the present application, the anti-radiation standard acquisition area 605 displays a list of nodes and their recommended anti-radiation standard values. The anti-radiation standard acquisition area 605 includes an anti-radiation standard input box 606 to obtain the anti-radiation standards of each node input by the user.

[0106] In some embodiments of the present application, the anti-radiation standard acquisition area 605 includes a one-key anti-radiation standard setting control 607. In response to a trigger instruction for the one-key anti-radiation standard setting control 607, the system automatically sets the anti-radiation standards of each node according to the recommended anti-radiation standard values of each node.

[0107] Step 507, in response to a trigger instruction for the on-board parameter saving control 608, save the lightweight level and anti-radiation standard to the model configuration database of the cloud-native architecture.

[0108] In step 507, in response to a trigger instruction for the on-board parameter saving control 608, the system saves the selected lightweight level and anti-radiation standard by the user to the model configuration database of the cloud-native architecture. This step ensures that all configuration parameters are accurately recorded, providing the necessary basic data support for subsequent model deployment and management, enabling the system to quickly retrieve and use these configuration parameters when needed.

[0109] In some embodiments of the present application, in step 103, in response to a trigger instruction for the model deployment control 102, the implementation process of displaying the model deployment sub-interface 300 includes but is not limited to steps 601 to 605.

[0110] Step 601, in response to a trigger instruction for the model deployment control 102, pass a second parameter to the model deployment algorithm of the cloud-native architecture to determine the lightweight packaging requirements and edge-cloud collaborative deployment requirements.

[0111] In step 601, in response to a trigger instruction for the model deployment control 102, the system passes the necessary second parameters to the model deployment algorithm in the cloud-native architecture. These parameters are used to determine the lightweight packaging requirements and edge-cloud collaborative deployment requirements, ensuring that subsequent operations can accurately meet the specific requirements of the user.

[0112] Step 602, according to the lightweight packaging requirements and edge-cloud collaborative deployment requirements, construct and display the model deployment sub-interface 300.

[0113] In step 602, based on the lightweight packaging requirements and edge-cloud collaborative deployment requirements obtained from step 601, the system dynamically constructs and displays a dedicated model deployment sub-interface 300. This interface provides an intuitive operating environment for users, enabling them to conveniently perform lightweight packaging and edge-cloud collaborative deployment settings, thereby optimizing the running performance and resource utilization efficiency of the satellite model.

[0114] In step 603, based on the lightweight level in the container template file and configuration parameters, a lightweight packaging control 301 is constructed in the model deployment sub-interface 300. In response to a trigger instruction for the lightweight packaging control 301, the containerization engine is called to perform dependency library trimming and binary compression processing on the model executable file to generate a lightweight container image of the satellite model.

[0115] It should be noted that the containerization engine is a software tool or platform used to create, manage, and run containerized applications. It packs and deploys an application and all its dependencies (such as libraries, configuration files, system tools, etc.) by providing an isolated running environment, ensuring the consistency and portability of the application in different computing environments. The core functions of the containerization engine include building container images, managing the container lifecycle, and coordinating communication between containers.

[0116] In step 603, based on the lightweight level in the container template file and configuration parameters, a lightweight packaging control 301 is created in the model deployment sub-interface 300. In response to a trigger instruction for the lightweight packaging control 301, the system first collects the model and all its dependency libraries according to the user-specified lightweight requirements and analyzes these dependency relationships to determine which libraries are necessary; then, the system trims off unnecessary dependency libraries and performs binary compression processing to reduce the file size and improve the loading speed; then, a lightweight container image is built using the optimized files through a container template (such as a Dockerfile); finally, the system validates and tests the generated image to ensure that it can run efficiently and stably in the target environment. This process ensures that the satellite model can achieve optimal performance in a resource-constrained on-board environment through automated tools and optimization techniques.

[0117] In step 604, based on the radiation resistance standard in the deployment template file and configuration parameters, a deployment configuration control 302 is constructed in the model deployment sub-interface 300. In response to a trigger instruction for the deployment configuration control 302, the node adapter of the edge-cloud collaborative engine is called to perform the following operations: Based on the radiation resistance standard, select on-board nodes with a cloud-native architecture and allocate fault-tolerant resources.

[0118] In step 604, according to the radiation resistance standards in the deployment template file and the configuration parameters, a deployment configuration control 302 is generated in the model deployment sub-interface 300. In response to a trigger instruction for the deployment configuration control 302, the system calls the node adapter of the edge-cloud collaboration engine, filters out suitable on-board nodes based on the radiation resistance standards, and allocates fault-tolerant resources. This step ensures that the satellite model can operate stably and reliably in a high-radiation environment, improving the overall reliability of the system.

[0119] In some embodiments of the present application, a lightweight telemetry framework (such as Prometheus and Grafana) is used to collect radiation data in real time, and the algorithm is deployed in the form of a Kubernetes Operator to monitor the radiation tolerance of nodes and dynamically update the radiation tolerance risk levels of nodes (such as high risk, medium risk, and low risk). According to the radiation resistance standards in the deployment template file and the configuration parameters, the edge-cloud collaboration engine realizes task migration and redundant replica allocation through the KubeEdge scheduler, automatically adjusts the Pod deployment configuration, and ensures seamless switching of tasks of nodes with lower radiation tolerance to high-tolerance nodes or the cloud.

[0120] Among them, KubeEdge is an open-source system designed to extend the capabilities of Kubernetes from the cloud to the edge computing environment, responsible for scheduling and deploying workloads on edge nodes. It enables users to run containerized applications on edge devices close to the data source and maintain seamless integration and management with the cloud platform. A Pod is the smallest deployable unit in Kubernetes, representing a collection of one or more containers (usually Docker containers) running in the cluster. Each Pod can contain one or more closely related containers that share storage, network, and standardized configuration options.

[0121] In some embodiments of the present application, the model deployment sub-interface 300 further includes a node management control. In response to a trigger instruction for the node management control, a node management sub-interface 700 is displayed. In a cloud-native architecture, a node refers to a computing resource unit in the system, which can be a physical machine, a virtual machine, or a container instance running environment, responsible for executing and managing the tasks of the satellite model. Each node has a certain computing power, storage capacity, and network connection, and can host and run one or more container instances, which contain the actual running satellite model and its dependencies.

[0122] Refer to Figure 8, the node management sub-interface 700 includes a node list area 701, a node label setting control 702, and a node selector control 703. Specifically, in the node list area 701, the basic information and running status of the nodes are displayed, including the node name such as "Node01", the current status of the node such as "Running" and "Alarm", the labels of the nodes such as "Worker Node", "Control Plane Node", etc., and the GPU capacity and memory capacity already allocated on the nodes, and the resource usage of the nodes is displayed in percentage form, such as CPU usage, memory usage, and the maximum number of container groups. In response to a trigger instruction for the node label setting control 702, a node label setting window is displayed to set corresponding node labels for the nodes, and the node labels are used to identify the attributes and functions of the nodes. In response to a trigger instruction for the node selector control 703, a node selector window is displayed, and corresponding node information is configured for the satellite model according to the node labels.

[0123] In some embodiments of the present application, the node management sub-interface 700 includes a node viewing control 704. Referring to Figure 9 , in response to a trigger instruction for the node viewing control 704, a node viewing sub-interface 800 is displayed. The node viewing sub-interface 800 includes a node information area 801 for displaying the detailed information of the nodes. For example, the node name is displayed as "Node69", which is the unique identifier of the node; the node status is displayed as "Running", indicating that the node is currently in a normal running state. The node label is displayed as "Worker Node", indicating that the node is mainly used to execute computing tasks; the operating system version of the node is displayed as "CentOS Linux 7 (Core)", the kernel version is displayed as "3.10.0-1160.45.2.el7.x86_64", the Docker version is displayed as "docker:19.03.12", and the Kubernetes version is displayed as "v1.21.5". The node viewing sub-interface 800 also displays the resource usage of the nodes. For example, the CPU usage of the node is "0.46%", the memory usage is "43.48%", the maximum number of container groups is "4.55%", and the disk usage is "0.11%".

[0124] In addition, the node viewing sub-interface 800 also displays the health status of the nodes, including the network connection status to ensure that the node can communicate with other nodes and services, the memory pressure situation to help monitor whether the memory usage is close to the upper limit, the disk pressure situation to check whether the disk space is sufficient, the process status to ensure smooth node scheduling to support task execution, and the node ready status to indicate whether the node is ready to receive new container groups, so as to ensure the stability and efficiency of the system. These detailed health status indicators enable users to comprehensively grasp the running status of the nodes and promptly discover and solve problems. Figure 8The example shows that the network connection status, memory pressure situation, disk pressure situation, process status, and node readiness status of the node "Node69" are all good.

[0125] Step 605: Deploy the lightweight container image to the on-board environment and cloud environment of the cloud-native architecture, and start the container instance to run the satellite model.

[0126] In step 605, the generated lightweight container image is deployed to the on-board environment and cloud environment of the cloud-native architecture, and the corresponding container instance is started to run the satellite model. In this way, not only the flexible deployment of the model in multiple environments is realized, but also its efficient and stable operation in different scenarios is ensured, maximizing the application value of the model.

[0127] In some embodiments of the present application, after the generated lightweight container image is deployed to the on-board environment and cloud environment of the cloud-native architecture, and the corresponding container instance is started to run the satellite model, the container instance viewing sub-interface 900 is displayed. Refer to Figure 10 , the container instance viewing sub-interface 900 includes a container instance information area 901. The basic information and running status of the container instance corresponding to the satellite model are displayed in the container instance information area 901, listing the key information of each container instance, including the container instance name (such as "tdsp_iseksim-5db9679bc-c462f" and "tdsp_iseksim-5db9679bc-c780b"), the node name (such as "Node67") and its corresponding node IP address (such as "10.37.3.217"), indicating the node where the container instance runs. In addition, the container group IP address corresponding to the container instance is also provided (such as "10.233.78.231" and "10.233.78.244"). In addition, the container instance information area 901 also provides the resource usage status information of the container instance, for example, the CPU usage rate is "1%", and the memory usage is "12%", so that users can comprehensively understand the performance of each container instance.

[0128] In some embodiments of the present application, the container instance information area 901 further includes a container instance log viewing control 902. In response to the trigger instruction for the container instance log viewing control 902, the container instance log viewing sub-interface 1000 is displayed. Refer to Figure 11 , the container instance log records are displayed in chronological order in the container instance log viewing sub-interface 1000, and each record contains detailed information. Among them, the timestamp of the log is accurate to milliseconds, such as "2023-07-25 16:47:59,827". The log levels are divided into different levels, such as INFO and WARN, etc. INFO represents the information level, and WARN represents the warning level.

[0129] In addition, the log source indicates the source code location or module name where the log is generated, such as "[com.alibaba.nacos.client.config.impl.ClientConfigManager]". The log message describes the events or state changes that occur during the operation of the container instance.

[0130] Specifically, a log message of a container instance is recorded as: "2023-07-25 16:47:59,827 [main]INFO com.alibaba.nacos.client.config.impl.ClientConfigManager", indicating that at the time "2023-07-25 16:47:59,827", the ClientConfigManager module generated an information-level log, which usually means that the module is notifying the user or developer about an event or state update in its normal operation process. For example, it may record the successful loading of the configuration. "2023-07-25 16:47:59,827 [main]WARN com.alibaba.nacos.client.config.impl.ClientConfigManager" records a warning-level log at the same time point, showing potential problems in the module. These detailed log records help to track and diagnose various situations during the operation of the container instance.

[0131] In some embodiments of the present application, in step 104, in response to a trigger instruction for the model management control 103, the implementation process of displaying the model management sub-interface 400 includes but is not limited to steps 701 to 707.

[0132] Step 701, in response to a trigger instruction for the model management control 103, pass a third parameter to the model management algorithm of the cloud-native architecture to determine the configuration parameter monitoring requirements, running state monitoring requirements, and version management requirements.

[0133] In step 701, in response to a trigger instruction for the model management control 103, the system sends a third parameter to the model management algorithm in the cloud-native architecture to determine the specific requirements for monitoring configuration parameters, running states, and version management, ensuring that subsequent operations can be carried out according to the actual needs of the user.

[0134] Step 702, according to the configuration parameter monitoring requirements, running state monitoring requirements, and version management requirements, construct and display the model management sub-interface 400.

[0135] In step 702, based on the requirements determined in the previous step (configuration parameter monitoring requirements, running status monitoring requirements, and version management requirements), the system constructs and displays a dedicated model management sub-interface 400. This interface provides an intuitive operating environment for users to manage and monitor various indicators of the satellite model.

[0136] In step 703, according to the data structure of the configuration parameters, a parameter monitoring area 401 is constructed in the model management sub-interface 400 to display the configuration parameters of the satellite model.

[0137] In step 703, in the model management sub-interface 400, a dedicated area is created according to the data structure of the configuration parameters to display various configuration parameters of the satellite model. The purpose of this is to enable users to clearly see the current model configuration at a glance, facilitating adjustments or optimizations.

[0138] In step 704, according to the real-time operation data of the edge-cloud collaboration engine, a running status monitoring area 402 is constructed in the model management sub-interface 400 to display the running status of the satellite model.

[0139] In step 704, through the real-time data provided by the edge-cloud collaboration engine, a running status monitoring area 402 is established in the model management sub-interface 400 to display the actual running status of the satellite model. This step helps users promptly understand the performance of the model and take measures for optimization or troubleshooting when necessary.

[0140] In step 705, based on the resource files of the satellite model and the historical version records of the configuration parameters, the version management algorithm of the cloud-native architecture is invoked to generate version switching rules and compatibility verification requirements.

[0141] In step 705, based on the resource files of the satellite model and the historical version records, the version management algorithm in the cloud-native architecture is invoked to generate version switching rules and compatibility check requirements. This process ensures the security and effectiveness of version switching and avoids problems caused by incompatibility.

[0142] In step 706, based on the version switching rules, a version switching control 403 is constructed in the model management sub-interface 400 and associated with the multi-version configuration files in the model configuration database.

[0143] In step 706, according to the generated version switching rules, a version switching control 403 is created in the model management sub-interface 400 and associated with the multi-version configuration files in the database. This makes it convenient for users to directly select and switch to the required version from the interface, improving the operation efficiency.

[0144] Step 707: In response to a trigger instruction for the version switching control 403, display a version switching window to load the resource files and configuration parameters of the target version, and complete the version switching of the satellite model.

[0145] In step 707, in response to a trigger instruction for the version switching control 403, the system will display a version switching window, load the resource files and configuration parameters of the target version, thereby completing the version switching of the satellite model. This step realizes the flexible management of the satellite model version and supports quick response to different business requirements or test scenarios.

[0146] In some embodiments of the present application, the implementation process of the version switching of the satellite model is as follows: After the user initiates a request through the version switching control 403 of the model management sub-interface 400, the system calls the version management algorithm to load the historical version records (including resource files, configuration parameters, and timestamps) in the model configuration database, dynamically generates a version switching window and displays all available version information (such as version number, update time, lightweight level, and compatibility status); detects target version dependency library conflicts, parameter adaptability, and resource occupancy prediction through an automated verification mechanism. If the verification passes, it automatically pulls the target version image, injects configuration parameters, and uses the Kubernetes Operator to restart the container instance to complete the hot replacement, while retaining the rollback snapshot; if an operation exception occurs, it automatically rolls back to the previous version within 10 seconds. This process realizes seamless switching through edge-cloud collaborative scheduling and pre-verification mechanism, ensuring the efficient management and reliable iteration of multi-version satellite models.

[0147] In some embodiments of the present application, the model management sub-interface 400 includes a model card area; among them, the model card area includes a parameter monitoring area 401, an operating status monitoring area 402, a version switching control 403, a model deletion control 404, a model download control 405, and a model operation control 406; in response to a trigger instruction for the model deletion control 404, delete the satellite model; in response to a trigger instruction for the model download control 405, display a model download window and download the relevant files of the satellite model; in response to a trigger instruction for the model operation control 406, run the satellite model.

[0148] In summary, the cloud-native based satellite model management method provided by the embodiments of the present application has the following technical effects.

[0149] Embodiments of the present application effectively simplify the entire process of satellite model from creation to operation by integrating model editing, deployment, and management functions into an integrated interface. Users can conveniently upload resource files, set configuration parameters, and optimize the model according to the lightweight level and radiation resistance standard to ensure its stable operation in the complex and ever-changing space environment. In addition, by using the edge-cloud collaboration engine, embodiments of the present application achieve flexible deployment of the model between the on-board environment and the cloud environment, which not only improves resource utilization but also enhances the reliability and flexibility of the system.

[0150] Furthermore, embodiments of the present application adopt containerization technology and automation tools to generate lightweight container images by performing dependency library trimming and binary compression processing on the model executable file, effectively reducing the storage space requirement and improving the operation efficiency. At the same time, embodiments of the present application provide comprehensive monitoring and version management functions, enabling users to track the operation status of the model in real time and perform quick switching or rollback as needed, ensuring business continuity and stability. These features together constitute an efficient and reliable satellite model management system, providing a solid guarantee for the successful execution of satellite missions.

[0151] Secondly, referring to Figure 12 , embodiments of the present application provide a cloud-native based satellite model management system, including a main interface module 810, a model editing module 820, a model deployment module 830, and a model management module 840.

[0152] The main interface module 810 is used to display the main interface of satellite model management based on the cloud-native architecture. Among them, the main interface of satellite model management includes a model editing control, a model deployment control, and a model management control. The model editing module 820 is used to respond to the trigger instruction for the model editing control, display the model editing sub-interface to obtain the resource files and configuration parameters of the satellite model. The resource files include the model executable file, the container template file, and the deployment template file, and the configuration parameters include basic parameters and on-board parameters. The on-board parameters include the lightweight level and the radiation resistance standard.

[0153] The model deployment module 830 is used to respond to the trigger instruction for the model deployment control, display the model deployment sub-interface, perform dependency library trimming and binary compression processing on the model executable file according to the lightweight level and the container template file to generate a lightweight container image of the satellite model, and deploy the lightweight container image to the on-board environment and the cloud environment of the cloud-native architecture through the edge-cloud collaboration engine, and start the container instance, and the container instance is used to run the satellite model. The model management module 840 is used to respond to the trigger instruction for the model management control, display the model management sub-interface to display the configuration parameters and operation status of the satellite model and manage the satellite model.

[0154] Second, referring to Figure 13 , an embodiment of the present application provides an electronic device, including: a processor 910 and a memory 920. The memory 920 is used to store programs. When the program is executed by the processor, the processor 910 implements the foregoing cloud-native satellite model management method.

[0155] In addition, an embodiment of the present application provides a computer-readable storage medium, in which there is a program executable by a processor. The program executable by the processor is used to implement the foregoing cloud-native satellite model management method when executed by the processor.

[0156] Similarly, the content in the above method embodiments is applicable to the system embodiments, electronic device embodiments, and medium embodiments. The functions specifically implemented by the system embodiments, electronic device embodiments, and medium embodiments are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those in the above method embodiments.

[0157] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that: various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and purposes of the present invention. The scope of the present invention is defined by the claims and their equivalents.

[0158] The above is a specific description of the preferred embodiments of the present invention, but the present invention is not limited to the embodiments. Those skilled in the art can also make various equivalent deformations or substitutions without violating the spirit of the present invention, and these equivalent deformations or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A satellite model management method based on cloud native, characterized in that It includes the following steps: Display the main interface of satellite model management based on the cloud-native architecture; wherein, the main interface of satellite model management includes a model editing control, a model deployment control, and a model management control; In response to a trigger instruction for the model editing control, display a model editing sub-interface to obtain the resource file and configuration parameters of the satellite model, where the resource file includes a model executable file, a container template file, and a deployment template file, and the configuration parameters include basic parameters and on-board parameters, and the on-board parameters include a lightweight level and an anti-radiation standard; In response to a trigger instruction for the model deployment control, display a model deployment sub-interface to perform dependency library trimming and binary compression processing on the model executable file according to the lightweight level and the container template file, generate a lightweight container image of the satellite model, and deploy the lightweight container image to the on-board environment and cloud environment of the cloud-native architecture through an edge-cloud collaboration engine, and start a container instance, where the container instance is used to run the satellite model; In response to a trigger instruction for the model management control, display a model management sub-interface to display the configuration parameters and running status of the satellite model and manage the satellite model.

2. The satellite model management method based on cloud native according to claim 1, wherein, The display of the main interface of satellite model management based on the cloud-native architecture includes: Automatically generate a model editing interface, a model deployment interface, and a model management interface in the cloud-native architecture, where the model editing interface is used to trigger the model editing algorithm of the cloud-native architecture, the model deployment interface triggers the model deployment algorithm of the cloud-native architecture, and the model management interface is used to trigger the model management algorithm of the cloud-native architecture; Create an initial page, and create a model editing control associated with the model editing interface, a model deployment control associated with the model deployment interface, and a model management control associated with the model management interface on the initial page to obtain the main interface of satellite model management; Display the main interface of satellite model management.

3. The method for managing satellite models based on cloud native according to claim 1, wherein, The display of the model editing sub-interface in response to a trigger instruction for the model editing control includes: In response to a trigger instruction for the model editing control, pass a first parameter to the model editing algorithm of the cloud-native architecture to determine the requirements for filling in the resource file and the configuration parameters; Construct and display the model editing sub-interface according to the requirements for filling in the resource file and the configuration parameters; Construct a resource file addition control in the model editing sub-interface according to the resource file filling rules, and in response to a trigger instruction for the resource file addition control, display a resource file addition window to obtain the resource file of the satellite model; Construct a configuration parameter acquisition control in the model editing sub-interface according to the configuration parameter filling rules, and in response to a trigger instruction for the configuration parameter acquisition control, display a configuration parameter acquisition window to obtain the configuration parameters of the satellite model.

4. The satellite model management method based on cloud native according to claim 3, characterized in that The configuration parameter acquisition window includes a basic parameter acquisition control; The display of the configuration parameter acquisition window to obtain the configuration parameters of the satellite model includes: In response to a trigger instruction for the basic parameter acquisition control, parse the data structure and input constraint conditions of the basic parameters according to the configuration parameter filling rules; Based on the data structure and input constraint conditions of the basic parameters, construct a basic parameter acquisition window; obtain the name, version number, type, development language, and task parameters of the satellite model as the basic parameters in the basic parameter acquisition window, and save them to the model configuration database of the cloud-native architecture.

5. The method for managing satellite models based on cloud native according to claim 3, wherein The configuration parameter acquisition window includes an on-board parameter acquisition control; The display configuration parameter acquisition window for obtaining the configuration parameters of the satellite model further includes: In response to a trigger instruction for the on-board parameter acquisition control, parse the data structure and input constraint conditions of the on-board parameters according to the configuration parameter filling rules; Based on the data structure and input constraint conditions of the on-board parameters, construct an on-board parameter acquisition window; wherein, the on-board parameter acquisition window includes a lightweight level acquisition area, a radiation resistance standard acquisition area, and an on-board parameter saving control; Call the lightweight classification algorithm to generate a recommended level list according to the resource occupancy rate of the model executable file; Display the recommended level list and obtain the lightweight level in the lightweight level acquisition area; the lightweight level is a weighted scoring level of the resource occupancy rate and calculation latency of the model executable file; Call the node status monitoring algorithm to generate a recommended radiation resistance standard value according to the radiation tolerance value of the nodes in the cloud-native architecture; display the recommended radiation resistance standard value and obtain the radiation resistance standard in the radiation resistance standard acquisition area; the radiation resistance standard is used to allocate redundant nodes in the cloud-native architecture; In response to a trigger instruction for the on-board parameter saving control, save the lightweight level and the radiation resistance standard to the model configuration database of the cloud-native architecture.

6. The satellite model management method based on cloud native according to claim 1, characterized in that The response to the trigger instruction for the model deployment control displays a model deployment sub-interface, including: In response to a trigger instruction for the model deployment control, pass a second parameter to the model deployment algorithm of the cloud-native architecture to determine the lightweight packaging requirement and the edge-cloud collaborative deployment requirement; Construct and display the model deployment sub-interface according to the lightweight packaging requirement and the edge-cloud collaborative deployment requirement; According to the container template file and the lightweight level in the configuration parameters, construct a lightweight packaging control in the model deployment sub-interface, and in response to a trigger instruction for the lightweight packaging control, call the containerization engine to perform dependency library trimming and binary compression processing on the model executable file to generate a lightweight container image of the satellite model; According to the anti-radiation standard in the deployment template file and configuration parameters, construct a deployment configuration control in the model deployment sub-interface, and in response to a trigger instruction for the deployment configuration control, call the node adapter of the edge-cloud collaboration engine to perform the following operations: Based on the anti-radiation standard, filter the spaceborne nodes of the cloud-native architecture and allocate fault-tolerant resources; Deploy the lightweight container image to the spaceborne environment and cloud environment of the cloud-native architecture, and start a container instance to run the satellite model.

7. The satellite model management method based on cloud native according to claim 1, wherein, In response to a trigger instruction for the model management control, display a model management sub-interface, including: In response to a trigger instruction for the model management control, pass a third parameter to the model management algorithm of the cloud-native architecture to determine the monitoring requirements for configuration parameters, the monitoring requirements for running status, and the version management requirements; Construct and display the model management sub-interface according to the monitoring requirements for configuration parameters, the monitoring requirements for running status, and the version management requirements; Construct a parameter monitoring area in the model management sub-interface according to the data structure of the configuration parameters to display the configuration parameters of the satellite model; Construct a running status monitoring area in the model management sub-interface according to the real-time running data of the edge-cloud collaboration engine to display the running status of the satellite model; Call the version management algorithm of the cloud-native architecture based on the historical version records of the resource file and configuration parameters of the satellite model to generate version switching rules and compatibility verification requirements; Based on the version switching rules, construct a version switching control in the model management sub-interface and associate it with the multi-version configuration files in the model configuration database; In response to a trigger instruction for the version switching control, display a version switching window to load the resource file and configuration parameters of the target version to complete the version switching of the satellite model.

8. A satellite model management system based on cloud native, characterized in that Including a main interface module, a model editing module, a model deployment module, and a model management module; The main interface module is used to display the main interface for satellite model management based on the cloud-native architecture; among them, the main interface for satellite model management includes a model editing control, a model deployment control, and a model management control; The model editing module is used to display a model editing sub-interface in response to a trigger instruction for the model editing control to obtain the resource file and configuration parameters of the satellite model. The resource file includes a model executable file, a container template file, and a deployment template file. The configuration parameters include basic parameters and spaceborne parameters. The spaceborne parameters include a lightweight level and an anti-radiation standard; The model deployment module is used to display a model deployment sub-interface in response to a trigger instruction for the model deployment control to perform dependency library trimming and binary compression processing on the model executable file according to the lightweight level and the container template file to generate a lightweight container image of the satellite model, and deploy the lightweight container image to the spaceborne environment and cloud environment of the cloud-native architecture through the edge-cloud collaboration engine, and start a container instance, and the container instance is used to run the satellite model; The model management module is configured to respond to a trigger instruction for the model management control, display a model management sub-interface to display the configuration parameters and operating status of the satellite model and manage the satellite model.

9. An electronic device, characterized in that, It includes: a processor and a memory; The memory is used to store a program; when the program is executed by the processor, the processor implements the cloud-native-based satellite model management method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a program executable by a processor, characterized in that, The program executable by the processor, when executed by the processor, is used to implement the cloud-native-based satellite model management method according to any one of claims 1 to 7.

Images