An onboard service change management system and method

Abstract

The application relates to the technical field of airborne service change, and discloses an airborne service change management system and method, which comprises an airborne end logic entity, the airborne end logic entity comprises an airborne server node, an airborne file warehouse node and an airborne service change management platform node, the airborne service change management platform node is in communication connection with the airborne server node and the airborne file warehouse node respectively, and the airborne server node is in communication connection with the airborne file warehouse node. The application solves the problems of long-time service interruption caused by airborne service change failure, low reliability and low safety of airborne service change and the like in the prior art.

Description

Technical Field

[0001] This invention relates to the field of airborne service change technology, specifically an airborne service change management system and method. Background Technology

[0002] The rapid growth of civil aviation aircraft data and route mileage has intensified competition in the aviation market. Consequently, airlines are seeking to enhance service quality and competitiveness by increasing the number and functionality of their in-flight business systems. With the development of in-flight information technology, the number of in-flight business systems is increasing, leading to growing challenges in managing in-flight service changes. Using container technology to manage the change process for in-flight services allows for rapid deployment of in-flight services using in-flight service images, enabling fast delivery of in-flight services, shortening the launch cycle, and significantly simplifying the launch process.

[0003] Currently, the onboard service change management methods used by airlines directly manipulate onboard server node resources without providing an independent operating environment for onboard services. This can lead to onboard service changes potentially affecting the normal operation of other onboard services.

[0004] Therefore, existing technologies suffer from problems such as: long-term business interruption due to failure of airborne service changes, low reliability and low security of airborne service changes. Summary of the Invention

[0005] To overcome the shortcomings of the prior art, the present invention provides an airborne service change management system and method, which solves the problems of long-term business interruption caused by airborne service change failure, low reliability and low security of airborne service changes in the prior art.

[0006] The technical solution adopted by the present invention to solve the above problems is:

[0007] An airborne service change management system includes an airborne logical entity, which includes an airborne server node, an airborne file repository node, and an airborne service change management platform node. The airborne service change management platform node is communicatively connected to the airborne server node and the airborne file repository node, respectively. The airborne server node is communicatively connected to the airborne file repository node.

[0008] As a preferred technical solution, the airborne server node includes one or more container management software and local images. The container management software communicates with the containers and services and the local images respectively. The container management software includes containers and services.

[0009] The airborne file repository node includes file transfer software, image repository, and service configuration repository. The image repository communicates with the local image.

[0010] The airborne service change management platform nodes include service change management software that communicates with each other. The service change management software communicates with the service configuration repository and container management software, respectively.

[0011] As a preferred technical solution, the roles and relationships of the airborne server node, airborne file repository node, and airborne service change management platform node are as follows:

[0012] The airborne file repository node centrally manages the airborne service image files and service configuration files required by the airborne services on all airborne server nodes. The airborne service image files provide the container base environment for the airborne services, and the service configuration files provide configuration information for the airborne services on the container base environment. The airborne file repository node retains historical versions of the container image files and service configuration files for each airborne service, providing basic data for the rollback of changes to the airborne services.

[0013] The airborne service change management platform node manages all changes to airborne services on airborne server nodes. It downloads the latest version of the service configuration file from the airborne service file management repository node, generates a container object creation plan and an operation execution plan based on the configuration information defined in the service configuration file, and calls the container management interface of the airborne server node in a set order to create the container according to the container object creation plan and the operation execution plan. It then runs and starts the airborne service and performs airborne service monitoring and detection operations on the container.

[0014] The onboard server node manages the lifecycle of its onboard services through container management software, and centrally manages the container objects that host the onboard services. The onboard server node downloads the onboard service images required by the onboard server node from the onboard file repository node, creates the virtual network and virtual storage that the containers depend on, creates and runs containers on the root file system provided by the onboard service image, monitors the running status of the containers, and manages the lifecycle of the containers.

[0015] As a preferred technical solution, the configuration information includes one or more of the following: basic service information, system resource configuration, resource permission configuration, and service dependency configuration.

[0016] As a preferred technical solution, the airborne service change management platform node stores all change record data of airborne services, the airborne file repository node centrally stores all airborne service images and airborne service configurations currently in use required by all airborne services, and the airborne file repository node centrally stores all airborne service images and airborne service configurations that have been used in previous versions required by all airborne services.

[0017] As a preferred technical solution, the image repository and the local image host communicate via the ARINC 615A file transfer protocol, the service change management software and the service configuration repository communicate via the ARINC 615A file transfer protocol, and the service change management software and the container management software communicate via the HTTP protocol.

[0018] An airborne service change management method, using the aforementioned airborne service change management system, automatically changes airborne services after detecting changes in service configuration or image, including the following steps:

[0019] A1, automatically connect to the terrestrial network to download files:

[0020] After the aircraft lands, the airborne document repository node automatically connects to the ground network, scans the ground for airborne service images and configuration files that can be transmitted to the airborne document repository node, and downloads the airborne service images and configuration files from the ground via the ARINC 615A file transfer protocol.

[0021] A2, Automatic Change of Onboard Services:

[0022] The airborne service change management platform node periodically checks the H256 checksum of the latest airborne service image and configuration file on the airborne file repository node and compares it with the H256 checksum of the airborne service image and configuration file used when the service was last changed in the change record. Based on the comparison result of the two H256 checksums, it determines whether the airborne service image and configuration file have been updated. If the airborne service image or configuration file has been updated, the change management platform node downloads the latest service configuration file from the airborne file repository node and deploys the airborne service to the corresponding airborne server node.

[0023] An airborne service change management method, using the aforementioned airborne service change management system, stops changing airborne services if verification of airborne services fails in an isolated verification environment, including the following steps:

[0024] B1. Create an airborne service isolation verification environment:

[0025] a) The airborne server node downloads the airborne service image required for airborne service changes from the airborne file repository node;

[0026] b) The host container management service starts a container management service that runs in a container to manage the isolated verification environment. The container management service that manages the isolated verification environment has an independent namespace, which is independent of the host container management service. The namespace of the container created by the container management service that manages the isolated verification environment for verifying changes to onboard services is nested in the namespace of the container management service that manages the isolated verification environment. It is independent of the container created by the host container management service for running real onboard services and does not affect each other.

[0027] c) The container management service for managing the isolated verification environment creates an onboard service change verification environment container and allocates computing resources to the onboard service change verification environment container that are consistent with the real onboard service container. It uses virtualization network technology and network namespace nesting technology to allocate network addresses to the onboard service change verification environment container that are consistent with the real onboard service container. It uses overlay storage technology to implement file-level snapshots and mounts the host file system mounted by the real onboard service container to the file system of the onboard service change verification environment container in the form of a snapshot, thus copying the file system of the real onboard service container.

[0028] B2, performing onboard service health checks in an isolated verification environment:

[0029] The airborne change management platform node sends airborne service health verification test cases to the airborne server node, and executes the airborne service health verification test cases in the airborne service change verification environment;

[0030] B3, Failed to verify the health of onboard services in an isolated environment:

[0031] The airborne server node feeds back the airborne service health check results to the airborne service change management platform node; the airborne service change management platform node records the health check results.

[0032] B4, Delete the onboard service isolation verification environment:

[0033] The airborne service change management platform node sends a request to delete the verification environment to the airborne server node, and the container management service that manages the isolated verification environment deletes the containers, virtual network resources, and virtual storage resources related to the airborne service verification environment.

[0034] An airborne service change management method, using the aforementioned airborne service change management system, if the airborne service is successfully verified in an isolated verification environment, then the old version of the airborne service container is stopped; the host container management service uses the new airborne service image to create and run the new version of the airborne service container, performs an airborne service health check, and if the health check of the new version of the airborne service fails, then the old version of the airborne service is started, including the following steps:

[0035] C1, Create an airborne service isolation verification environment:

[0036] C2 performs onboard service health checks in an isolated verification environment:

[0037] C3, Delete the onboard service isolation verification environment:

[0038] C4, discontinue older versions of onboard service containers:

[0039] The airborne change management platform node sends a request to stop airborne services to the airborne server node, and the host container management service stops the running airborne service container before the change.

[0040] C5, Create and start the new version of the onboard services container

[0041] The airborne change management platform node sends a request to the airborne server node to create and start a new version of the airborne service container. The host container management service uses the new airborne service image to create and run the new version of the airborne service container.

[0042] C6 performs onboard service health checks in the new version of the onboard service container:

[0043] The airborne service change management platform node sends airborne service health verification test cases to the airborne server node, and the airborne server node executes the airborne service health verification test cases in the new version of the airborne service container.

[0044] C7, in the new version of the onboard service container, the onboard service health check failed to be performed:

[0045] The airborne server node feeds back the airborne service health check results to the airborne service change management platform node; the airborne service change management platform node records the health check results.

[0046] C8, start the old version of the onboard service container:

[0047] The airborne change management platform node sends a request to start the airborne service container before the change to the airborne server node. The airborne container management software deletes the new version of the airborne service container and starts the old version of the airborne service container.

[0048] An airborne service change management method, using the aforementioned airborne service change management system, if the airborne service health verification is successful in both the isolation verification environment and the real environment, then the airborne service container before the change is deleted, and the airborne service container after the change is used to provide airborne business functions, including the following steps:

[0049] D1, Create an airborne service isolation verification environment:

[0050] D2, Perform onboard service health checks in an isolated verification environment:

[0051] D3, Delete the onboard service isolation verification environment:

[0052] D4, Stop the running onboard service container:

[0053] D5, Create and start the new version of the onboard services container:

[0054] D6, performs onboard service health checks on the new version of the onboard service container:

[0055] D7, Remove the previous onboard service container:

[0056] The airborne change management platform node sends a request to the airborne server node to delete the airborne service container before the change, and the airborne container management software deletes the airborne service container before the change.

[0057] Compared with the prior art, the present invention has the following advantages:

[0058] (1) This invention proposes an automatic change mechanism for airborne services, which can automatically download airborne service change files after the aircraft lands, simplifying the airborne service change process, improving the efficiency of airborne service maintenance, and reducing the maintenance cost of airborne services.

[0059] (2) The present invention designs an airborne service health verification mechanism, establishes a verification environment that is isolated from the real airborne service and has consistent resource configuration, avoids the impact of the verification environment on airborne services, improves the accuracy of verification, and reduces the impact of airborne service change process on airborne services.

[0060] (3) This invention proposes a centralized management and storage mechanism to centrally manage all changes to airborne services and centrally store the airborne service images and airborne service configurations that airborne service changes depend on, thereby simplifying the change process of airborne services, improving the reliability of airborne service changes, and increasing the utilization rate of airborne server node resources. Attached Figure Description

[0061] Figure 1 This is a schematic diagram of a typical system architecture for an airborne service change management system according to the present invention;

[0062] Figure 2 for Figure 1 One of the magnified views of a section;

[0063] Figure 3 for Figure 1 The second enlarged view of a section;

[0064] Figure 4 Automatic change flowchart for airborne services;

[0065] Figure 5 for Figure 4 One of the magnified views of a section;

[0066] Figure 6 for Figure 4 The second enlarged view of a section;

[0067] Figure 7 Flowchart of a scenario where health testing fails in an isolation environment;

[0068] Figure 8 for Figure 7 One of the magnified views of a section;

[0069] Figure 9 for Figure 7 The second enlarged view of a section;

[0070] Figure 10 A flowchart illustrating a real-world scenario where an airborne service health check fails.

[0071] Figure 11 for Figure 10 One of the magnified views of a section;

[0072] Figure 12 for Figure 10 The second enlarged view of a section;

[0073] Figure 13 Flowchart of a successful airborne service health detection scenario in a real-world environment;

[0074] Figure 14 for Figure 13 One of the magnified views of a section;

[0075] Figure 15 for Figure 13 The second enlarged view of a part. Detailed Implementation

[0076] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0077] Example 1

[0078] like Figures 1 to 15 As shown, the container-based method for managing changes to airborne services on civil aircraft is designed to meet the needs of a civil aircraft project for unified management of airborne service changes, ensuring that upgrades and changes are recorded, their history is traceable, and upgrade failures can be rolled back, thereby reducing business interruption time caused by upgrades. This method, specifically for civil aircraft airborne services, designs an airborne service change management approach. It verifies changes to airborne services in a verification environment isolated from the actual airborne environment but with consistent resource configurations. During verification, the airborne services provide normal airborne business. After successful verification, the airborne services are changed in the actual airborne environment. This solves the problem of prolonged business interruption caused by failed airborne service changes, improving the reliability and security of airborne service changes.

[0079] Due to the complexity of airborne systems, the diversity of airborne service dependencies on airborne system resources and the variability of their operating states, as well as the diversity of airborne system networks, a container-based method for managing changes to civil aircraft airborne services was designed to meet the requirements for the integrity and consistency of the operating environment before and after changes to airborne services. This method includes system architecture, automatic change mechanism for airborne services, airborne service health verification mechanism, centralized management and storage mechanism.

[0080] This invention has the following features:

[0081] (1) System architecture: including logical entities such as airborne document repository node, airborne service change management platform node, and airborne server node, as well as the main functions of the above logical entities and their interconnection relationships;

[0082] (2) Automatic change mechanism for airborne services: including methods for detecting changes in service configuration or image and automatically changing airborne services;

[0083] (3) Airborne service health verification mechanism: including the process of creating a verification environment that is isolated from the real airborne service and has the same resource configuration before the airborne service is changed, and only using the changed airborne service to provide airborne services after successful verification;

[0084] (4) Centralized management and storage mechanism: including methods for centrally managing changes to airborne services on all airborne server nodes and centrally storing airborne service images and airborne service configuration files that airborne service changes depend on.

[0085] Detailed description is as follows:

[0086] (I) System Architecture

[0087] A typical system architecture for a container-based method for managing changes to onboard services of civil aircraft is as follows: Figure 1 As shown.

[0088] like Figure 1 The system architecture shown includes the following airborne logical entities: airborne server node, airborne file repository node, and airborne service change management platform node.

[0089] To implement onboard service change management based on container technology, the roles and relationships of each logical entity are as follows:

[0090] (1) The airborne file repository node centrally manages the airborne service image files and service configuration files required by airborne services on all airborne server nodes. The airborne service image files provide the container base environment for the airborne services, while the service configuration files, within the container base environment, provide the airborne services with basic service information (name, version, service deployment address, etc.), system resource configuration, resource permission configuration, and service dependency configuration. The airborne file repository node retains a certain number of historical versions of container image files and service configuration files for each airborne service, providing basic data for rollback of changes to the airborne services.

[0091] (2) The airborne service change management platform node manages the change behavior of airborne services on all airborne server nodes, downloads the latest version of the service configuration file from the airborne service file management repository node, and generates a container object creation plan and service operation and health detection execution plan based on the service basic information (name, version, service deployment address, etc.), system resource configuration, resource permission configuration, service inter-dependency configuration and other configuration information defined in the service configuration file. According to these plans, the container management interface of the airborne server node is called in a certain order to create containers, and services are run and service health status detection is performed on the containers.

[0092] (3) The onboard server node manages the lifecycle of its onboard services through container management software, and centrally manages the container objects carrying the onboard services based on the OCI (Open Container Initiative Specification) container standard. The onboard server node downloads the onboard service images required by the onboard server node from the onboard file repository node, creates the virtual network and virtual storage that the containers depend on, creates and runs containers on the root file system provided by the onboard service image, monitors the running status of the containers, and manages the lifecycle of the containers.

[0093] (II) Automatic Change Mechanism for Airborne Services

[0094] The design incorporates a mechanism to automatically update onboard services after changes to the service configuration or image. The specific process is as follows:

[0095] 1) Automatically connect to the terrestrial network to download files.

[0096] After the aircraft lands, the airborne document repository node automatically connects to the ground network. It scans the ground network for airborne service images and configuration files that can be transmitted to the airborne document repository node. It then downloads the airborne service images and configuration files from the ground using the ARINC 615A airborne file transfer protocol. To ensure the accuracy and consistency of the downloaded files, the file signature is verified after downloading to ensure that the downloaded file belongs to the document repository node. The content of the downloaded file is also verified to ensure its consistency.

[0097] 2) Automatically change onboard services

[0098] The airborne service change management platform node periodically checks the H256 checksum of the latest service image and configuration file on the airborne file repository node and compares it with the H256 checksum of the airborne service image and configuration file used when the service was last changed in the change record. Based on the comparison result of the two H256 checksums, it determines whether the airborne service image and configuration file have been updated. If the airborne service image or configuration file has been updated, the change management platform node downloads the latest service configuration file from the airborne file repository node through the airborne file transfer protocol ARINC 615A and deploys the airborne service to the corresponding airborne server node according to the address of the airborne server node in the airborne service configuration file.

[0099] Automatic change process for onboard services, such as Figure 4 As shown.

[0100] (III) Airborne Service Health Verification Mechanism

[0101] To mitigate the impact of onboard service changes on onboard operations, a verification environment isolated from the actual onboard services is established. This avoids any influence from the verification environment on onboard operations. Simultaneously, container-related resource isolation technologies such as network virtualization, storage virtualization, and namespace nesting are used to create an isolated verification environment consistent with the actual onboard service runtime environment. This improves the accuracy of verifying the health of onboard services in the isolated verification environment and reduces the false positive rate of onboard service health verification results caused by differences in runtime environments. During the period of verifying the health of changed onboard services in the isolated verification environment, the onboard services running in the actual environment continue to provide onboard services normally, ensuring the continuity of onboard operations. If the verification of onboard services in the isolated verification environment fails, the onboard service change is stopped. The scenario process is as follows:

[0102] 1) Create an airborne service isolation verification environment

[0103] a) The airborne server node downloads the airborne service image required for airborne service changes from the airborne file repository node;

[0104] b) The host container management service starts a container management service that runs in a container to manage the isolated verification environment. The container management service that manages the isolated verification environment has an independent namespace, which is independent of the host container management service. The namespace of the container created by the container management service that manages the isolated verification environment for verifying changes to onboard services is nested in the namespace of the container management service that manages the isolated verification environment. It is independent of the container created by the host container management service for running real onboard services and does not affect each other.

[0105] c) The container management service for managing the isolated verification environment creates an onboard service change verification environment container and allocates computing resources to the onboard service change verification environment container that are consistent with the real onboard service container. It uses virtualization network technology and network namespace nesting technology to allocate network addresses to the onboard service change verification environment container that are consistent with the real onboard service container. It uses overlay storage technology to implement file-level snapshots (a copy-on-write technology) and mounts the host file system mounted by the real onboard service container to the file system of the onboard service change verification environment container in the form of a snapshot. This quickly replicates the file system of the real onboard service container to ensure the consistency and isolation of data between the verification environment and the real environment.

[0106] 2) Perform onboard service health checks in an isolated verification environment.

[0107] The airborne change management platform node sends airborne service health verification test cases to the airborne server node, and executes the airborne service health verification test cases in the airborne service change verification environment;

[0108] 3) Failure to verify the health of onboard services in an isolated environment

[0109] The airborne server node reports the reasons for the failure of the airborne service health verification, the failure rate of the test cases, and the execution time to the airborne service change management platform node; the airborne service change management platform node records the health test results information.

[0110] 4) Delete the onboard service isolation verification environment

[0111] The airborne service change management platform node sends a request to delete the verification environment to the airborne server node, and the container management service that manages the isolated verification environment deletes the containers, virtual network resources, and virtual storage resources related to the airborne service verification environment.

[0112] Scenarios where health testing fails in isolation environments, such as Figure 7 As shown.

[0113] If the onboard service is successfully verified in the isolated verification environment, the old version of the onboard service container is stopped. This allows for a quick rollback to the old version of the onboard service in case of a failed onboard service change. The host container management service uses the new onboard service image to create and run the new version of the onboard service container, and performs an onboard service health check. If the health check of the new version of the onboard service fails, the old version of the onboard service is started. The process is as follows:

[0114] 1) Create an airborne service isolation verification environment

[0115] 2) Perform onboard service health checks in an isolated verification environment.

[0116] 3) Delete the onboard service isolation verification environment

[0117] 4) Stop the old version of the onboard service container

[0118] The airborne change management platform node sends a request to stop airborne services to the airborne server node, and the host container management service stops the running airborne service container before the change.

[0119] 5) Create and start the new version of the onboard services container

[0120] The airborne change management platform node sends a request to the airborne server node to create and start a new version of the airborne service container. The host container management service uses the new airborne service image to create and run the new version of the airborne service container.

[0121] 6) Perform onboard service health checks on the new version of the onboard service container.

[0122] The airborne service change management platform node sends airborne service health verification test cases to the airborne server node, and the airborne server node executes the airborne service health verification test cases in the new version of the airborne service container.

[0123] 7) Onboard service health check failed in the new version of the onboard service container.

[0124] The airborne server node reports information such as the reasons for the failure of the airborne service health check, the failure rate of the test cases, and the execution time to the airborne service change management platform node; the airborne service change management platform node records the health check results information.

[0125] 8) Start the old version of the onboard service container

[0126] The airborne change management platform node sends a request to start the airborne service container before the change to the airborne server node. The airborne container management software deletes the new version of the airborne service container and starts the old version of the airborne service container.

[0127] Real-world airborne service health check failure scenario process as follows: Figure 10 As shown.

[0128] If the health verification of the airborne service is successful in both the isolated verification environment and the real environment, then the airborne service container before the change is deleted, and the airborne service container after the change is used to provide airborne business functions. The scenario process is as follows:

[0129] 1) Create an airborne service isolation verification environment

[0130] 2) Perform onboard service health checks in an isolated verification environment.

[0131] 3) Delete the onboard service isolation verification environment

[0132] 4) Stop the running onboard service container

[0133] 5) Create and start the new version of the onboard services container

[0134] 6) Perform onboard service health checks on the new version of the onboard service container.

[0135] 7) Delete the previous airborne service container.

[0136] The airborne change management platform node sends a request to delete the airborne service container before the change to the airborne server node, and the airborne container management software deletes the airborne service container before the change.

[0137] Real-world onboard service health check success process as follows: Figure 13 As shown.

[0138] (iv) Centralized Management and Storage Mechanism

[0139] The airborne service change management platform node centrally manages all changes to airborne services on all airborne server nodes. Airborne server nodes do not need to design change management mechanisms or reside change management services, simplifying the change process for airborne services, freeing up resources on airborne server nodes, and improving resource utilization. Airborne services do not need to adapt to the change management mechanisms designed for airborne server nodes, allowing them to focus on airborne business functions and improving the versatility and scalability of airborne services.

[0140] The airborne service change management platform controls the change process of airborne services on all airborne server nodes from a global perspective. It analyzes the dependencies between different airborne services from a global perspective, controls the order of airborne service changes, and improves the controllability of airborne service changes. It also enables concurrent changes to airborne services without dependencies, thereby improving the efficiency of airborne service changes.

[0141] The airborne service change management platform stores all change records for airborne services, making it easier to trace the change history and improve troubleshooting efficiency when functional or performance issues arise in airborne services later.

[0142] The airborne file repository node centrally stores all airborne service images and configurations that are currently in use or have been used in the past. This facilitates tracing the airborne service images and configurations of past versions and rolling back airborne services to a specified historical version, thereby improving the reliability of airborne server node change management.

[0143] After centrally storing the images and configurations of airborne server nodes, the airborne server nodes only retain the airborne service images currently in use, thereby improving the storage space utilization of the airborne server nodes.

[0144] The advantages of this invention are as follows:

[0145] (1) An automatic change mechanism for airborne services is proposed, which can automatically download airborne service change files after the aircraft lands, simplify the airborne service change process, improve the efficiency of airborne service maintenance, and reduce the maintenance cost of airborne services.

[0146] (2) Design an airborne service health verification mechanism, establish a verification environment that is isolated from the real airborne service and has consistent resource configuration, avoid the impact of the verification environment on airborne services, improve the accuracy of verification, and reduce the impact of airborne service change process on airborne services.

[0147] (3) A centralized management and storage mechanism is proposed to centrally manage all changes to airborne services and centrally store the airborne service images and airborne service configurations that airborne service changes depend on, thereby simplifying the change process of airborne services, improving the reliability of airborne service changes, and increasing the utilization rate of airborne server node resources.

[0148] As described above, the present invention can be implemented well.

[0149] All features disclosed in all embodiments of this specification, or steps in all methods or processes implied in the disclosure, may be combined and / or extended or replaced in any way, except for mutually exclusive features and / or steps.

[0150] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Based on the technical essence of the present invention, any simple modifications, equivalent substitutions, and improvements made to the above embodiments within the spirit and principles of the present invention shall still fall within the protection scope of the present invention.

Claims

1. An airborne service change management system, characterized in that, It includes airborne logical entities, which include: airborne server node, airborne file repository node, and airborne service change management platform node. The airborne service change management platform node is communicatively connected to the airborne server node and the airborne file repository node, respectively. The airborne server node is communicatively connected to the airborne file repository node. The airborne server node includes one or more container management software and local images. The container management software communicates with containers and services and local images respectively. The container management software includes containers and services. The airborne file repository node includes file transfer software, image repository, and service configuration repository. The image repository communicates with the local image. The airborne service change management platform nodes include service change management software that communicates with each other. The service change management software communicates with the service configuration repository and container management software, respectively. The roles and relationships of the airborne server node, airborne document repository node, and airborne service change management platform node are as follows: The airborne file repository node centrally manages the airborne service image files and service configuration files required by the airborne services on all airborne server nodes. The airborne service image files provide the container base environment for the airborne services, and the service configuration files provide configuration information for the airborne services on the container base environment. The airborne file repository node retains historical versions of the container image files and service configuration files for each airborne service, providing basic data for the rollback of changes to the airborne services. The airborne service change management platform node manages all changes to airborne services on airborne server nodes. It downloads the latest version of the service configuration file from the airborne service file management repository node, generates a container object creation plan and an operation execution plan based on the configuration information defined in the service configuration file, and calls the container management interface of the airborne server node in a set order to create the container according to the container object creation plan and the operation execution plan. It then runs and starts the airborne service and performs airborne service monitoring and detection operations on the container. The onboard server node manages the lifecycle of its onboard services through container management software, and centrally manages the container objects that host the onboard services. The onboard server node downloads the onboard service images required by the onboard server node from the onboard file repository node, creates the virtual network and virtual storage that the containers depend on, creates and runs containers on the root file system provided by the onboard service image, monitors the running status of the containers, and manages the lifecycle of the containers.

2. The airborne service change management system according to claim 1, characterized in that, Configuration information includes one or more of the following: basic service information, system resource configuration, resource permission configuration, and service dependency configuration.

3. The airborne service change management system according to claim 2, characterized in that, The airborne service change management platform node stores all change records for airborne services. The airborne file repository node centrally stores all airborne service images and configurations currently in use and required by all airborne services. The airborne file repository node centrally stores all airborne service images and configurations of historical versions that have been used and required by all airborne services.

4. An airborne service change management system according to any one of claims 1 to 3, characterized in that, The image repository and the local image host communicate via the ARINC 615A file transfer protocol. The service change management software and the service configuration repository communicate via the ARINC 615A file transfer protocol. The service change management software and the container management software communicate via the HTTP protocol.

5. A method for managing changes to airborne services, characterized in that, Using the airborne service change management system according to any one of claims 1 to 4, the system automatically changes airborne services after detecting changes in service configuration or image, including the following steps: A1, automatically connect to the terrestrial network to download files: After the aircraft lands, the airborne document repository node automatically connects to the ground network, scans the ground for airborne service images and configuration files that can be transmitted to the airborne document repository node, and downloads the airborne service images and configuration files from the ground via the ARINC 615A file transfer protocol. A2, Automatic Change of Onboard Services: The airborne service change management platform node periodically checks the H256 checksum of the latest airborne service image and configuration file on the airborne file repository node and compares it with the H256 checksum of the airborne service image and configuration file used when the service was last changed in the change record. Based on the comparison result of the two H256 checksums, it determines whether the airborne service image and configuration file have been updated. If the airborne service image or configuration file has been updated, the change management platform node downloads the latest service configuration file from the airborne file repository node and deploys the airborne service to the corresponding airborne server node.

6. A method for managing airborne service changes, characterized in that, Using the airborne service change management system according to any one of claims 1 to 4, if the verification of airborne services in the isolated verification environment fails, the change of airborne services is stopped, comprising the following steps: B1. Create an airborne service isolation verification environment: a) The airborne server node downloads the airborne service image required for airborne service changes from the airborne file repository node; b) The host container management service starts a container management service that runs in a container to manage the isolated verification environment. The container management service that manages the isolated verification environment has an independent namespace, which is independent of the host container management service. The namespace of the container created by the container management service that manages the isolated verification environment for verifying changes to onboard services is nested in the namespace of the container management service that manages the isolated verification environment. It is independent of the container created by the host container management service for running real onboard services and does not affect each other. c) The container management service for managing the isolated verification environment creates an onboard service change verification environment container and allocates computing resources to the onboard service change verification environment container that are consistent with the real onboard service container. It uses virtualization network technology and network namespace nesting technology to allocate network addresses to the onboard service change verification environment container that are consistent with the real onboard service container. It uses overlay storage technology to implement file-level snapshots and mounts the host file system mounted by the real onboard service container to the file system of the onboard service change verification environment container in the form of a snapshot, thus copying the file system of the real onboard service container. B2, performing onboard service health checks in an isolated verification environment: The airborne change management platform node sends airborne service health verification test cases to the airborne server node, and executes the airborne service health verification test cases in the airborne service change verification environment; B3, Failed to verify the health of onboard services in an isolated environment: The airborne server node feeds back the airborne service health check results to the airborne service change management platform node; the airborne service change management platform node records the health check results. B4, Delete the onboard service isolation verification environment: The airborne service change management platform node sends a request to delete the verification environment to the airborne server node, and the container management service that manages the isolated verification environment deletes the containers, virtual network resources, and virtual storage resources related to the airborne service verification environment.

7. A method for managing changes to airborne services, characterized in that, Using the airborne service change management system according to any one of claims 1 to 4, if the airborne service is successfully verified in the isolated verification environment, the old version of the airborne service container is stopped. The host container management service uses the new onboard service image to create and run the new version of the onboard service container, performs an onboard service health check, and if the health check for the new version of the onboard service fails, it starts the old version of the onboard service, including the following steps: C1, Create an airborne service isolation verification environment: C2 performs onboard service health checks in an isolated verification environment: C3, Delete the onboard service isolation verification environment: C4, discontinue older versions of onboard service containers: The airborne change management platform node sends a request to stop airborne services to the airborne server node, and the host container management service stops the running airborne service container before the change. C5, Create and start the new version of the onboard services container The airborne change management platform node sends a request to the airborne server node to create and start a new version of the airborne service container. The host container management service uses the new airborne service image to create and run the new version of the airborne service container. C6 performs onboard service health checks in the new version of the onboard service container: The airborne service change management platform node sends airborne service health verification test cases to the airborne server node, and the airborne server node executes the airborne service health verification test cases in the new version of the airborne service container. C7, in the new version of the onboard service container, the onboard service health check failed to be performed: The airborne server node feeds back the airborne service health check result information to the airborne service change management platform node; The airborne service change management platform records health check results information at each node. C8, start the old version of the onboard service container: The airborne change management platform node sends a request to start the airborne service container before the change to the airborne server node. The airborne container management software deletes the new version of the airborne service container and starts the old version of the airborne service container.

8. A method for managing changes to airborne services, characterized in that, Using the airborne service change management system according to any one of claims 1 to 4, if the airborne service health verification is successful in both the isolated verification environment and the real environment, the airborne service container before the change is deleted, and the airborne service container after the change is used to provide airborne business functions, including the following steps: D1, Create an airborne service isolation verification environment: D2, Perform onboard service health checks in an isolated verification environment: D3, Delete the onboard service isolation verification environment: D4, Stop the running onboard service container: D5, Create and start the new version of the onboard services container: D6, performs onboard service health checks on the new version of the onboard service container: D7, Remove the previous onboard service container: The airborne change management platform node sends a request to the airborne server node to delete the airborne service container before the change, and the airborne container management software deletes the airborne service container before the change.

Images