Method and system for testing test process before rocket launching based on cloud platform

Abstract

The invention discloses a method and a system for testing a test process before rocket launching based on a cloud platform. The method for testing the test process before rocket launching based on the cloud platform comprises the following steps: creating and configuring a container cluster; configuring a user permission and a project space, and performing user management; deploying a network and storage configuration; deploying a test application; multi-dimensional monitoring is set; and performing a test process test. According to the method for carrying out the flow test before rocket launching based on the cloud platform, the stability and reliability of the flow test can be ensured. And meanwhile, a popular, flexible and easily-expanded system architecture and framework are adopted, so that test information interaction before emission of longitudinal integration and transverse integration of the system can be met.

Description

A cloud-based method and system for testing rocket pre-launch test procedures. Technical Field

[0001] This application relates to the aerospace field, specifically to a method and system for conducting pre-launch test procedures for rockets based on a cloud platform. Background Technology

[0002] Ground-based telemetry, tracking, and command (TT&C) systems are a crucial component of aerospace systems, and pre-launch test procedures are of paramount importance, serving as a key factor in ensuring the success of spaceflight tests. Traditional test procedures typically employ a centralized architecture of "central computer + front-end data acquisition," where all data is aggregated into a central processing unit for judgment and decision-making. On the hardware side, system functions are often deeply tied to specialized hardware; different rocket models and missions may require entirely different test hardware. Traditional test procedures are "tailor-made" for specific hardware and rocket models, with system functions largely fixed in the initial design phase, making it extremely difficult to add new test items or control logic later. This excessive reliance on the central node results in poor system robustness; a failure of the central computer can paralyze the entire TT&C process, posing a significant risk to the launch mission. In terms of hardware, system functions are often deeply tied to dedicated hardware, making upgrades difficult. Upgrading system functions often requires replacing a large amount of hardware due to slow hardware updates, resulting in high costs and long cycles. Moreover, different rocket models and missions may require completely different test, launch, and control hardware, leading to resource non-reusability and complex assurance. Therefore, accurate, rapid, integrated, intelligent, and cloud-platform-based testing processes have become essential conditions for ensuring reliable testing of aerospace systems.

[0003] Therefore, how to provide a test procedure testing method that improves the accuracy, speed, and intelligence of test procedure testing has become an urgent problem to be solved in this field. Summary of the Invention

[0004] To address the aforementioned issues, this application proposes a cloud platform-based method for testing the pre-launch test process of rockets, comprising the following steps: creating and configuring a container cluster; after completing the container cluster configuration, configuring user permissions and project space, and managing users; after completing the user permission and project space configuration, deploying network and storage configurations; after completing network deployment and storage configuration, deploying the test application; after the test application is deployed, setting up multi-dimensional monitoring; after the multi-dimensional monitoring is set up, conducting the test process test.

[0005] The test method for rocket pre-launch testing based on a cloud platform, as described above, includes creating and configuring a container cluster, which involves: determining the cluster's configuration parameters and determining the network plugins.

[0006] The test method for rocket pre-launch testing based on a cloud platform, as described above, includes the following sub-steps for deploying network and storage configurations: selecting and setting network models and access configurations; and setting container resource quotas and storage configurations.

[0007] The test method for rocket pre-launch test procedures based on a cloud platform, as described above, includes Underlay and Overlay network models, with the platform selecting the network model according to the cluster plan.

[0008] The test method for rocket pre-launch test process based on cloud platform described above includes setting container resource quotas, which involves specifying the number of CPU cores and memory size for each test application, as well as configuring container orchestration and scheduling strategies.

[0009] A cloud-based system for testing pre-launch rocket experiments includes: a container cluster creation and configuration unit, a user permission and project space configuration unit, a network deployment and storage configuration unit, a test application deployment unit, a multi-dimensional monitoring setting unit, and an experiment process testing unit. The container cluster creation and configuration unit is used to create and configure a container cluster; the user permission and project space configuration unit is used to configure user permissions and project space for user management; the network deployment and storage configuration unit is used to deploy network and storage configurations; the test application deployment unit is used to deploy test applications; the multi-dimensional monitoring setting unit is used to set up multi-dimensional monitoring; and the experiment process testing unit is used to perform experiment process testing.

[0010] The test system for rocket pre-launch testing based on a cloud platform, as described above, includes a container cluster creation and configuration unit that creates and configures a container cluster, including: determining the cluster's configuration parameters; and determining the network plugins.

[0011] The cloud-based test system for rocket pre-launch testing processes, as described above, includes the following sub-steps in its network deployment and storage configuration unit: selecting and setting the network model and access configuration; and setting container resource quotas and storage configurations.

[0012] The cloud-based test system for rocket pre-launch testing processes, as described above, includes an Underlay and Overlay network model in its network deployment and storage configuration unit. The platform selects the network model based on the cluster plan.

[0013] The cloud-based test system for rocket pre-launch testing, as described above, includes a network deployment and storage configuration unit that sets container resource quotas, which includes specifying the number of CPU cores and memory size for each test application, as well as configuring container orchestration and scheduling strategies.

[0014] This application has the following beneficial effects:

[0015] The cloud-based method for pre-launch process testing proposed in this application ensures the stability and reliability of the testing process. It also employs a popular, flexible, and easily scalable system architecture and framework, enabling vertical and horizontal integration of pre-launch test information exchange. Furthermore, it fully considers user experience, providing a user-friendly interface with convenient interaction and simple operation. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0017] Figure 1 is a schematic flowchart of a cloud platform-based test procedure for rocket pre-launch testing provided according to an embodiment of this application;

[0018] Figure 2 is a schematic diagram of the internal structure of a cloud-based test system for rocket pre-launch testing procedures provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0020] This application proposes a method and system for testing the pre-launch test process of rockets based on a cloud platform. The cloud platform is application-centric, fully integrated, ready to use out of the box, and rapidly deployable, covering the entire application lifecycle. Addressing the centralized risks of traditional solutions, the cloud platform employs a distributed, networked, cloud-native architecture to mitigate these risks. It overcomes the limitations of traditional customized and periodic solutions through platformization and modularization, improves data utilization through a data-driven, full lifecycle management approach, and supports system upgrades through hardware and software decoupling.

[0021] Example 1

[0022] As shown in Figure 1, this embodiment provides a method for testing the pre-launch test process of a rocket based on a cloud platform, which specifically includes the following steps:

[0023] Step S1: Create and configure the container cluster.

[0024] The cloud platform (hereinafter referred to as the "platform") manages the lifecycle of the cluster based on Kubernetes containers, including the creation, viewing, and deletion of the cluster.

[0025] It provides support solutions for private cloud, virtualization, and physical machine resources, all of which can deploy container clusters and have universal adaptability. The cluster management provides platform administrators with operation and maintenance tools and can provide a user-friendly graphical interface for operation and management, including managing clusters, networks, image repositories, and platform management nodes. Necessary software is installed on the above nodes and a Kubernetes cluster is built.

[0026] Understandably, containers are lightweight virtualization units implemented based on Docker technology, which can package applications and their dependencies into standardized images, enabling arbitrary execution after building.

[0027] As an example, the administrator selects 8 physical servers from the infrastructure resource pool as initial computing nodes through a unified cluster management module web interface.

[0028] Determine the configuration parameters for the specified cluster, which are Kubernetes version (v1.24), container runtime (containerd), Pod network segment (10.244.0.0 / 16), and service network segment (10.96.0.0 / 12).

[0029] Determine network plugins (e.g., Underlay mode) to meet the requirements for low-latency, fixed IP communication between the test system and the rocket's front-end equipment.

[0030] Finally, click "Create Cluster." The system will automatically install the necessary software on all nodes and build a Kubernetes cluster. After successful creation, the interface will display the cluster health status, node list, and total resources.

[0031] Step S2: After completing the container cluster configuration, configure user permissions and project space, and manage users.

[0032] It employs a role-based access control (RBAC) scheme. A role is a collection of permissions. The product provides pre-defined role templates, allowing for the rapid creation of custom roles and supporting fine-grained setting of user permissions.

[0033] Multiple roles can be assigned to staff within a project and will take effect in one or more container clusters associated with the project.

[0034] Role-based access control is adopted, which assigns different permissions to different roles and then associates each role with different users, so that different users have different permissions.

[0035] The platform offers its own user system to meet the needs of multi-level management. It also supports integration with a unified authentication platform to achieve unified login and access control.

[0036] As an example, the administrator enters the access control module, interfaces with the existing unified identity authentication system, and synchronizes the organizational structure and user information of the testing team. Project X is created, and the corresponding Kubernetes namespace is automatically generated. Finally, user roles are assigned: "Engineer Wang" and "Engineer Li" are added as project administrators, possessing full management permissions within the project. Test engineers such as "Engineer Zhang" and "Engineer Liu" are added as test engineers, possessing permissions such as application deployment and log viewing. "Engineer Zhao" from the quality department is added as a read-only observer, only able to view test status and reports.

[0037] Step S3: After completing the user permissions and project space configuration, deploy the network and storage configuration.

[0038] Step S3 includes the following sub-steps:

[0039] Step S31: Select and configure the network model and access settings.

[0040] The application deployment supports a cluster network mode, allowing for the deployment of a suitable network model according to the cluster plan.

[0041] Specifically, you can choose between the Underlay and Overlay network models supported by the platform based on your cluster plan. Underlay is suitable for low-latency scenarios, while Overlay is suitable for flexible scaling scenarios. To meet the various network environment factors that may occur in actual deployment, you can select network plugins such as Flannel, Calico, and Kube-OVN through the graphical interface and configure plugin parameters (such as Calico's MTU value and Flannel's network mode).

[0042] Furthermore, the platform's network is configured according to the cluster plan, deploying a suitable network model and network mode, and setting up domain names for external access to workloads to provide external access. The platform imports external traffic into the Kubernetes cluster through software load balancing.

[0043] As an example, create an Ingress resource, configure an external access domain name (such as test-rocket.caspace.cn), and map it to the Service port of the test application within the cluster. Use soft load balancing to import traffic from outside the cluster into the internal network.

[0044] Step S32: Set container resource quotas and storage configuration.

[0045] Setting container resource quotas includes specifying the number of CPU cores (e.g., 2 cores) and memory size (e.g., 4GB) for each test application, as well as configuring container orchestration and scheduling policies to ensure that the container platform can correctly orchestrate and schedule containers under different policies. For example, it can perform balanced scheduling based on node resource utilization or schedule to specific hardware nodes.

[0046] Furthermore, it can also perform container health checks.

[0047] In storage configuration, the platform supports full lifecycle management of storage volumes, including creation and deletion. Furthermore, once a storage volume is assigned to a container service, it can be automatically mounted. Even if container instances migrate between host machines, the storage volume can automatically mount along with the container, requiring no manual intervention. It supports containers using local host storage, and the path to use local storage can be specified through the platform interface. This provides visualized storage management capabilities.

[0048] Step S4: After completing the network and storage configuration, deploy the test application.

[0049] The platform defines and deploys applications via graphical interfaces or service orchestration YAML files. It supports resource management, including single-container resource limits; service management, including health checks, parameterized configuration, and load balancing; service orchestration Configmap and Secret configuration; and service orchestration network configuration.

[0050] Step S4 includes the following sub-steps:

[0051] Step S41: Determine the application to be deployed and configure the application parameters.

[0052] To deploy graphically, fill in the application name and namespace, select the test application image in the private repository, and set the number of container instances.

[0053] Configuring application parameters includes setting the service address, port (such as data receiving port 8080), environment variables (such as test number, test timeout threshold), custom container CMD parameters, and selecting the container specification.

[0054] Step S42: Perform application health checks and application lifecycle management.

[0055] The platform supports multiple health check methods. Select the check method, set the monitoring period (e.g., 10 seconds / time) and failure threshold (e.g., 3 failures to determine a fault), and automatically restart the container instance when a service failure is detected.

[0056] It also configures automatic scaling up and down, sets scaling up and down rules based on monitoring metrics (such as CPU utilization ≥70%), specifies the minimum number of instances and the maximum number of instances, and automatically increases container replicas when the test load increases and automatically shrinks when the load decreases.

[0057] Application lifecycle management includes state management for creation, startup, stop, restart, and deletion; it supports configuration management, including instance size, service address, service port, environment variables, log configuration, and custom container CMD parameters; it supports selection of common container sizes and allows customization of service container sizes.

[0058] Once the application is deployed, you can check its status (e.g., running, abnormal, or stopped). It supports manual startup, stop, restart, and deletion operations, and records the log of each operation (including the operator, time, and result).

[0059] Step S5: After the test application is deployed, set up multi-dimensional monitoring.

[0060] The operations and maintenance center provides platform administrators with unified full-stack PaaS capabilities for monitoring, logging, events, alarms, and notifications. The platform employs multi-layered and multi-dimensional monitoring and alarming across clusters, hosts, platform components, applications, and containers. In practical applications, it is the only container platform to provide a customizable centralized monitoring dashboard. The platform's monitoring data is persistently stored and provides API support to meet the needs of integrating with proprietary monitoring platforms. The platform offers visualized monitoring of container performance metrics, displaying application running status in real time, and provides storage, collection, and analysis functions for container log information; it also provides management capabilities for various critical events. Relevant log information is obtained through the log service, supporting log filtering and viewing based on log type, project, namespace, application, time, and other dimensions. Based on Kubernetes auditing integration, the platform supports recording all user operation records, providing security-related time-series operation records. Through auditing, platform auditors can clearly understand changes occurring in the Kubernetes cluster. Combining its own capabilities, the platform supports viewing events on the platform, quickly understanding various operations and details, facilitating troubleshooting and monitoring. It allows searching for events not only by keywords such as namespace, event type, resource name, and resource type, but also by custom tags, and supports viewing event details.

[0061] Based on the above, step S5 includes the following sub-steps:

[0062] Step S51: Configure multi-dimensional monitoring.

[0063] This involves identifying the monitoring targets, including clusters, hosts, platform components, applications, containers, etc., setting the monitoring frequency, and determining the core monitoring metrics.

[0064] Key monitoring metrics include CPU utilization, memory utilization, network throughput, container restart count, and data processing latency.

[0065] Step S52: Perform log and event management.

[0066] This includes enabling log collection, selecting container log sources, configuring log storage periods, and supporting filtering and retrieval by log type, project, and time range before exporting logs in a specified format.

[0067] In event management, you can set event filtering conditions (such as namespace, event type, resource type), view operation events in real time (such as Pod scheduling failure, storage volume mounting success), and search event details by keyword, so as to quickly locate the cause of the failure.

[0068] Step S53: Configure alarms and auditing.

[0069] In the alarm configuration, set the trigger conditions, specify the alarm level (e.g., emergency, normal), select the notification method (e.g., email or in-platform message), and associate the recipients (e.g., test manager, operations personnel).

[0070] The triggering conditions include CPU utilization exceeding a specified threshold, container restarts exceeding a specified number of times, and data processing delays exceeding a specified time.

[0071] For example, when the triggering conditions reach the emergency alarm level, an email reminder will be sent to the operations and maintenance personnel.

[0072] The audit configuration includes recording all user operations (such as application deployment and permission changes), generating time-series operation records, supporting retrieval by operator, time, and operation object, and ensuring that operations are traceable.

[0073] Step S6: After the multi-dimensional monitoring settings are completed, conduct the experimental process test.

[0074] The test is conducted by issuing instructions for the pre-launch test procedures and relying on the application services deployed on the platform to obtain latency data in real time.

[0075] The following are the specific methods for performing tests on application services deployed on the platform:

[0076] Step S61: Confirm that the application service deployment is ready.

[0077] The process involves logging into the platform and verifying the status of relevant application services within the application service system. These services include data processing software, client service software, communication and storage software, big data software, main control software, health monitoring client software, data receiving, data parsing, and data preprocessing modules. It is crucial to ensure all services are running and that container instances meet testing requirements. If requirements are not met, adjustments can be made through scaling up or down.

[0078] Verify the application configuration to ensure that the service address, port, environment variables, and Configmap / Secret parameters are consistent with the test requirements, and perform an application health check.

[0079] Check network connectivity. If the cluster network plugin is running normally, the external access domain name is configured, and test command traffic can be successfully imported into the cluster application through soft load balancing, then proceed to step S62.

[0080] Step S62: Initiate the pre-launch test procedure for the rocket.

[0081] Testers can log in to the platform via the main control client software and enter their dedicated test space. It is important to note that this step is only available to authorized users.

[0082] After logging into the platform, test commands are issued sequentially according to the preset test procedures (such as propulsion system testing, attitude control system calibration, data transmission link verification, etc.). The test commands are transmitted to the corresponding application services through the service ports configured in the platform network.

[0083] It supports two types of command issuance: the first is single command issuance, and the second is batch command issuance by defining the command execution order and interval through a service orchestration YAML file.

[0084] Step S63: Perform data acquisition and processing.

[0085] After receiving the instruction, the application service executes the test according to the preset logic, collects latency data in real time, and uploads it to the platform.

[0086] The platform automatically performs data parsing, preprocessing, and fusion, storing the fused multi-source data in a data storage system. This system supports automatic mounting of storage volumes and data persistence. The storage system is based on the DateSong big data management platform.

[0087] As is understandable, data parsing involves data format conversion, data preprocessing involves filtering outlier data, and data fusion involves integrating data from multiple sources. All of these methods can be implemented using existing techniques, and the specific procedures will not be elaborated upon again.

[0088] During the test, you can view the data processing progress and intermediate results in real time, and you can filter and query by time, data type and other dimensions.

[0089] Step S64: Monitor the testing process and handle any faults.

[0090] The platform enables multi-dimensional monitoring, allowing users to view application service CPU / memory usage, data processing latency, and container running status in real time. Key metrics can be visualized through a custom monitoring dashboard.

[0091] It collects application runtime logs and command execution logs through a log service, supporting filtering by project, time, and log type (error / warning) to quickly locate the cause of command execution anomalies. It also tracks key events such as service scheduling and storage mounting through event management.

[0092] Step S65: If an unexpected event occurs in the server or application, perform automatic fault handling.

[0093] If a server or application service encounters an unexpected event, Kubernetes will automatically reschedule the application to another compute node.

[0094] Furthermore, when a base node fails, the system automatically identifies the failure and migrates the service to other nodes. The failed node is marked as unavailable and no longer deploys containers.

[0095] After a node recovers from a failure, it will automatically rejoin the cluster.

[0096] When a container service experiences a visible failure, the platform automatically restarts the instance. It also periodically detects hidden failures (such as exceeding the service connection limit) through health checks and takes appropriate action.

[0097] Example 2

[0098] As shown in Figure 2, a cloud platform-based test system for rocket pre-launch test procedures is provided in an embodiment of this application. Specifically, it includes: a container cluster creation and configuration unit 210, a user permission and project space configuration unit 220, a network deployment and storage configuration unit 230, a test application deployment unit 240, a multi-dimensional monitoring setting unit 250, and a test procedure testing unit 260.

[0099] Container cluster creation configuration unit 210 is used to create and configure container clusters.

[0100] The cloud platform (hereinafter referred to as the "platform") manages the lifecycle of the cluster based on Kubernetes containers, including the creation, viewing, and deletion of the cluster.

[0101] It provides support solutions for private cloud, virtualization, and physical machine resources, all of which can deploy container clusters and have universal adaptability. The cluster management provides platform administrators with operation and maintenance tools and can provide a user-friendly graphical interface for operation and management, including managing clusters, networks, image repositories, and platform management nodes. Necessary software is installed on the above nodes and a Kubernetes cluster is built.

[0102] Understandably, containers are lightweight virtualization units implemented based on Docker technology, which can package applications and their dependencies into standardized images, enabling arbitrary execution after building.

[0103] As an example, the administrator selects 8 physical servers from the infrastructure resource pool as initial computing nodes through a unified cluster management module web interface.

[0104] Determine the configuration parameters for the specified cluster, which are Kubernetes version (v1.24), container runtime (containerd), Pod network segment (10.244.0.0 / 16), and service network segment (10.96.0.0 / 12).

[0105] Determine network plugins (e.g., Underlay mode) to meet the requirements for low-latency, fixed IP communication between the test system and the rocket's front-end equipment.

[0106] Finally, click "Create Cluster." The system will automatically install the necessary software on all nodes and build a Kubernetes cluster. After successful creation, the interface will display the cluster health status, node list, and total resources.

[0107] User permissions and project space configuration unit 220 is used to configure user permissions and project space and manage users after the container cluster configuration is completed.

[0108] It employs a role-based access control (RBAC) scheme. A role is a collection of permissions. The product provides pre-defined role templates, allowing for the rapid creation of custom roles and supporting fine-grained setting of user permissions.

[0109] Multiple roles can be assigned to staff within a project and will take effect in one or more container clusters associated with the project.

[0110] Role-based access control is adopted, which assigns different permissions to different roles and then associates each role with different users, so that different users have different permissions.

[0111] The platform offers its own user system to meet the needs of multi-level management. It also supports integration with a unified authentication platform to achieve unified login and access control.

[0112] As an example, the administrator enters the access control module, interfaces with the existing unified identity authentication system, and synchronizes the organizational structure and user information of the testing team. Project X is created, and the corresponding Kubernetes namespace is automatically generated. Finally, user roles are assigned: "Engineer Wang" and "Engineer Li" are added as project administrators, possessing full management permissions within the project. Test engineers such as "Engineer Zhang" and "Engineer Liu" are added as test engineers, possessing permissions such as application deployment and log viewing. "Engineer Zhao" from the quality department is added as a read-only observer, only able to view test status and reports.

[0113] The network deployment and storage configuration unit 230 is used to deploy network and storage configurations after completing user permissions and project space configurations.

[0114] The network deployment and storage configuration unit 230 includes the following sub-steps:

[0115] Step Q1: Select and configure the network model and access settings.

[0116] The application deployment supports a cluster network mode, allowing for the deployment of a suitable network model according to the cluster plan.

[0117] Specifically, you can choose between the Underlay and Overlay network models supported by the platform based on your cluster plan. Underlay is suitable for low-latency scenarios, while Overlay is suitable for flexible scaling scenarios. To meet the various network environment factors that may occur in actual deployment, you can select network plugins such as Flannel, Calico, and Kube-OVN through the graphical interface and configure plugin parameters (such as Calico's MTU value and Flannel's network mode).

[0118] Furthermore, the platform's network is configured according to the cluster plan, deploying a suitable network model and network mode, and setting up domain names for external access to workloads to provide external access. The platform imports external traffic into the Kubernetes cluster through software load balancing.

[0119] As an example, create an Ingress resource, configure an external access domain name (such as test-rocket.caspace.cn), and map it to the Service port of the test application within the cluster. Use soft load balancing to import traffic from outside the cluster into the internal network.

[0120] Step Q2: Configure container resource quotas and storage settings.

[0121] Setting container resource quotas includes specifying the number of CPU cores (e.g., 2 cores) and memory size (e.g., 4GB) for each test application, as well as configuring container orchestration and scheduling policies to ensure that the container platform can correctly orchestrate and schedule containers under different policies. For example, it can perform balanced scheduling based on node resource utilization or schedule to specific hardware nodes.

[0122] Furthermore, it can also perform container health checks.

[0123] In storage configuration, the platform supports full lifecycle management of storage volumes, including creation and deletion. Furthermore, once a storage volume is assigned to a container service, it can be automatically mounted. Even if container instances migrate between host machines, the storage volume can automatically mount along with the container, requiring no manual intervention. It supports containers using local host storage, and the path to use local storage can be specified through the platform interface. This provides visualized storage management capabilities.

[0124] The test application deployment unit 240 is used to deploy test applications after completing network and storage configuration.

[0125] The platform defines and deploys applications via graphical interfaces or service orchestration YAML files. It supports resource management, including single-container resource limits; service management, including health checks, parameterized configuration, and load balancing; service orchestration Configmap and Secret configuration; and service orchestration network configuration.

[0126] The test application deployment unit 240 includes the following sub-steps:

[0127] Step V1: Determine the application to deploy and configure application parameters.

[0128] To deploy graphically, fill in the application name and namespace, select the test application image in the private repository, and set the number of container instances.

[0129] Configuring application parameters includes setting the service address, port (such as data receiving port 8080), environment variables (such as test number, test timeout threshold), custom container CMD parameters, and selecting the container specification.

[0130] Step V2: Perform application health checks and application lifecycle management.

[0131] The platform supports multiple health check methods. Select the check method, set the monitoring period (e.g., 10 seconds / time) and failure threshold (e.g., 3 failures to determine a fault), and automatically restart the container instance when a service failure is detected.

[0132] It also configures automatic scaling up and down, sets scaling up and down rules based on monitoring metrics (such as CPU utilization ≥70%), specifies the minimum number of instances and the maximum number of instances, and automatically increases container replicas when the test load increases and automatically shrinks when the load decreases.

[0133] Application lifecycle management includes state management for creation, startup, stop, restart, and deletion; it supports configuration management, including instance size, service address, service port, environment variables, log configuration, and custom container CMD parameters; it supports selection of common container sizes and allows customization of service container sizes.

[0134] Once the application is deployed, you can check its status (e.g., running, abnormal, or stopped). It supports manual startup, stop, restart, and deletion operations, and records the log of each operation (including the operator, time, and result).

[0135] The multi-dimensional monitoring setting unit 250 is used to set up multi-dimensional monitoring after the test application is deployed.

[0136] The operations and maintenance center provides platform administrators with unified full-stack PaaS capabilities for monitoring, logging, events, alarms, and notifications. The platform employs multi-layered and multi-dimensional monitoring and alarming across clusters, hosts, platform components, applications, and containers. In practical applications, it is the only container platform to provide a customizable centralized monitoring dashboard. The platform's monitoring data is persistently stored and provides API support to meet the needs of integrating with proprietary monitoring platforms. The platform offers visualized monitoring of container performance metrics, displaying application running status in real time, and provides storage, collection, and analysis functions for container log information; it also provides management capabilities for various critical events. Relevant log information is obtained through the log service, supporting log filtering and viewing based on log type, project, namespace, application, time, and other dimensions. Based on Kubernetes auditing integration, the platform supports recording all user operation records, providing security-related time-series operation records. Through auditing, platform auditors can clearly understand changes occurring in the Kubernetes cluster. Combining its own capabilities, the platform supports viewing events on the platform, quickly understanding various operations and details, facilitating troubleshooting and monitoring. It allows searching for events not only by keywords such as namespace, event type, resource name, and resource type, but also by custom tags, and supports viewing event details.

[0137] Based on the above, the multi-dimensional monitoring setting unit 250 includes the following sub-steps:

[0138] Step D1: Configure multi-dimensional monitoring.

[0139] This involves identifying the monitoring targets, including clusters, hosts, platform components, applications, containers, etc., setting the monitoring frequency, and determining the core monitoring metrics.

[0140] Key monitoring metrics include CPU utilization, memory utilization, network throughput, container restart count, and data processing latency.

[0141] Step D2: Perform log and event management.

[0142] This includes enabling log collection, selecting container log sources, configuring log storage periods, and supporting filtering and retrieval by log type, project, and time range before exporting logs in a specified format.

[0143] In event management, you can set event filtering conditions (such as namespace, event type, resource type), view operation events in real time (such as Pod scheduling failure, storage volume mounting success), and search event details by keyword, so as to quickly locate the cause of the failure.

[0144] Step D3: Configure alarms and auditing.

[0145] In the alarm configuration, set the trigger conditions, specify the alarm level (e.g., emergency, normal), select the notification method (e.g., email or in-platform message), and associate the recipients (e.g., test manager, operations personnel).

[0146] The triggering conditions include CPU utilization exceeding a specified threshold, container restarts exceeding a specified number of times, and data processing delays exceeding a specified time.

[0147] For example, when the triggering conditions reach the emergency alarm level, an email reminder will be sent to the operations and maintenance personnel.

[0148] The audit configuration includes recording all user operations (such as application deployment and permission changes), generating time-series operation records, supporting retrieval by operator, time, and operation object, and ensuring that operations are traceable.

[0149] The test process test unit 260 is used to perform test process testing after the multi-dimensional monitoring settings are completed.

[0150] The test is conducted by issuing instructions for the pre-launch test procedures and relying on the application services deployed on the platform to obtain latency data in real time.

[0151] The following are the specific methods for performing tests on application services deployed on the platform:

[0152] Step F1: Confirm that the application service is deployed and ready.

[0153] The process involves logging into the platform and verifying the status of relevant application services within the application service system. These services include data processing software, client service software, communication and storage software, big data software, main control software, health monitoring client software, data receiving, data parsing, and data preprocessing modules. It is crucial to ensure all services are running and that container instances meet testing requirements. If requirements are not met, adjustments can be made through scaling up or down.

[0154] Verify the application configuration to ensure that the service address, port, environment variables, and Configmap / Secret parameters are consistent with the test requirements, and perform an application health check.

[0155] Check network connectivity. If the cluster network plugin is running normally, the external access domain name is configured, and test command traffic can be successfully imported into the cluster application through soft load balancing, then proceed to step S62.

[0156] Step F2: Initiate the pre-launch test procedure for the rocket.

[0157] Testers can log in to the platform via the main control client software and enter their dedicated test space. It is important to note that this step is only available to authorized users.

[0158] After logging into the platform, test commands are issued sequentially according to the preset test procedures (such as propulsion system testing, attitude control system calibration, data transmission link verification, etc.). The test commands are transmitted to the corresponding application services through the service ports configured in the platform network.

[0159] It supports two types of command issuance: the first is single command issuance, and the second is batch command issuance by defining the command execution order and interval through a service orchestration YAML file.

[0160] Step F3: Perform data acquisition and processing.

[0161] After receiving the instruction, the application service executes the test according to the preset logic, collects latency data in real time, and uploads it to the platform.

[0162] The platform automatically performs data parsing, preprocessing, and fusion, storing the fused multi-source data in a data storage system. This system supports automatic mounting of storage volumes and data persistence. The storage system is based on the DateSong big data management platform.

[0163] As is understandable, data parsing involves data format conversion, data preprocessing involves filtering outlier data, and data fusion involves integrating data from multiple sources. All of these methods can be implemented using existing techniques, and the specific procedures will not be elaborated upon again.

[0164] During the test, you can view the data processing progress and intermediate results in real time, and you can filter and query by time, data type and other dimensions.

[0165] Step F4: Monitor the testing process and handle any faults.

[0166] The platform enables multi-dimensional monitoring, allowing users to view application service CPU / memory usage, data processing latency, and container running status in real time. Key metrics can be visualized through a custom monitoring dashboard.

[0167] It collects application runtime logs and command execution logs through a log service, supporting filtering by project, time, and log type (error / warning) to quickly locate the cause of command execution anomalies. It also tracks key events such as service scheduling and storage mounting through event management.

[0168] Step F5: If an unexpected event occurs in the server or application, automatic fault handling will be performed.

[0169] If a server or application service encounters an unexpected event, Kubernetes will automatically reschedule the application to another compute node.

[0170] Furthermore, when a base node fails, the system automatically identifies the failure and migrates the service to other nodes. The failed node is marked as unavailable and no longer deploys containers.

[0171] After a node recovers from a failure, it will automatically rejoin the cluster.

[0172] When a container service experiences a visible failure, the platform automatically restarts the instance. It also periodically detects hidden failures (such as exceeding the service connection limit) through health checks and takes appropriate action.

[0173] This application also provides a computer storage medium storing computer instructions, which, when invoked, are used to execute the cloud-based pre-launch test procedure method for rockets.

[0174] The embodiments disclosed in this invention provide a computer-readable storage medium storing computer program instructions. When the computer program instructions are executed on a computer, the computer performs the aforementioned method for testing the pre-launch test process of a rocket based on a cloud platform.

[0175] This invention provides a processor for processing the above-described method for conducting pre-launch test procedures for rockets based on a cloud platform.

[0176] In this embodiment of the invention, the processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0177] The various methods, steps, and logic diagrams disclosed in the embodiments of this invention can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor reads information from the storage medium and, in conjunction with its hardware, completes the steps of the above methods.

[0178] The storage medium can be memory, such as volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0179] Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM).

[0180] This application has the following beneficial effects:

[0181] The cloud-based method for pre-launch process testing proposed in this application ensures the stability and reliability of the testing process. It also employs a popular, flexible, and easily scalable system architecture and framework, enabling vertical and horizontal integration of pre-launch test information exchange. Furthermore, it fully considers user experience, providing a user-friendly interface with convenient interaction and simple operation.

[0182] Although the examples referenced in this application are described for illustrative purposes only and not for limiting the scope of this application, changes, additions and / or deletions to the implementation may be made without departing from the scope of this application.

[0183] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for testing the pre-launch test process of a rocket based on a cloud platform, characterized in that, Includes the following steps: Create and configure a container cluster; after completing the container cluster configuration, configure user permissions and project space, and manage users. After completing the user permissions and project space configuration, deploy the network and storage configuration; After completing network deployment and storage configuration, deploy the test application; after the test application is deployed, set up multi-dimensional monitoring; after the multi-dimensional monitoring is set up, conduct experimental process testing.

2. The method for testing the pre-launch test process of a rocket based on a cloud platform as described in claim 1, characterized in that, Creating and configuring a container cluster includes: determining the cluster's configuration parameters; and determining the network plugins.

3. The method for testing the pre-launch test process of a rocket based on a cloud platform as described in claim 1, characterized in that, Deploying network and storage configurations includes the following sub-steps: selecting and configuring the network model and access settings; and setting container resource quotas and storage configurations.

4. The method for testing the pre-launch test process of a rocket based on a cloud platform as described in claim 3, characterized in that, The network model includes Underlay and Overlay network models, and the platform selects the network model based on the cluster plan.

5. The method for testing the pre-launch test process of a rocket based on a cloud platform as described in claim 3, characterized in that, Setting container resource quotas includes specifying the number of CPU cores and memory size for each test application, as well as configuring container orchestration and scheduling policies.

6. A cloud platform-based test system for pre-launch rocket testing procedures, characterized in that, include: The system includes a container cluster creation configuration unit, a user permission and project space configuration unit, a network deployment and storage configuration unit, a test application deployment unit, a multi-dimensional monitoring settings unit, and an experimental process testing unit. The container cluster creation configuration unit is used to create and configure container clusters; the user permissions and project space configuration unit is used to configure user permissions and project space for user management; and the network deployment and storage configuration unit is used to deploy network and storage configurations. The test application deployment unit is used to deploy test applications; The multi-dimensional monitoring settings unit is used to configure multi-dimensional monitoring. The test procedure test unit is used to perform test procedure tests.

7. The cloud platform-based test system for rocket pre-launch testing procedures as described in claim 6, characterized in that, The container cluster creation configuration unit creates and configures a container cluster, including: determining the cluster's configuration parameters; and determining the network plugins.

8. The cloud platform-based test system for rocket pre-launch testing procedures as described in claim 6, characterized in that, The network deployment and storage configuration unit includes the following sub-steps: selecting and setting the network model and access configuration; and setting container resource quotas and storage configuration.

9. The cloud platform-based test system for rocket pre-launch testing procedures as described in claim 8, characterized in that, The network models in the network deployment and storage configuration unit include Underlay and Overlay network models, and the platform selects the network model according to the cluster plan.

10. The cloud platform-based test system for rocket pre-launch testing procedures as described in claim 8, characterized in that, The network deployment and storage configuration unit sets container resource quotas, including specifying the number of CPU cores and memory size for each test application, as well as configuring container orchestration and scheduling policies.

Images