An OTA upgrading method and system of a satellite on-board computing platform and a computer storage medium

Abstract

This invention discloses an OTA upgrade method for a satellite-borne computing platform, comprising the following steps: upon receiving an upgrade command, generating an image differential package based on the current on-orbit image and the target image, simultaneously generating a Docker Compose change package bound to the target image and a unified upgrade manifest, and signing it with a ground private key; transmitting data via a satellite-to-ground link; the onboard OTA Agent receiving data in a fragmented manner and verifying the signature; after all fragments are received, verifying the unified upgrade manifest signature using a preset public key; if verification is successful, performing resource-aware image differential restoration and restoring the target image based on the on-orbit image; the restored target image being re-verified by Digest and then pushed to the onboard local registry; selecting a secure upgrade window to pull the target image from the local registry for upgrade. This invention also provides an OTA upgrade system for a satellite-borne computing platform and a computer storage medium.

Description

Technical Field

[0001] This invention relates to the field of on-orbit software maintenance in commercial aerospace, and in particular to a satellite-ground collaborative OTA upgrade method, system, and computer storage medium for a satellite-borne microservice containerized computing platform. Background Technology

[0002] Commercial spaceflight is a crucial sector for cultivating new productive forces. It lowers the barriers to space exploration, drives the iteration of space technology, and spawns new industries such as satellite internet, space computing power, and on-orbit services. It deeply empowers sectors like agriculture, disaster prevention, and communications, becoming a new engine for global economic growth and a core force in building a spacefaring superpower. With a limited total amount of low-Earth orbit frequency resources, following a "first-come, first-served" rule, the world is scrambling to seize the commercial spaceflight market and aggressively acquiring orbital frequency resources. China is also accelerating its satellite network project, making commercial spaceflight a core arena for technological and strategic competition among nations.

[0003] As commercial space satellites gradually shift from single payload control to onboard edge computing, intelligent processing, and containerized deployment, onboard services are no longer limited to fixed binary programs. Instead, they are defined by multiple microservice Docker images, image digests, Compose service definitions, environment variables, mount directories, port mappings, startup order, health checks, and service dependencies. Traditional on-orbit upgrade (OTA) solutions for satellites are mainly geared towards monolithic or embedded software and lack the unified management capabilities and coordinated upgrade mechanisms for the aforementioned containerized multi-service versions. Moreover, existing containerized upgrade solutions on the ground heavily rely on stable, high-speed networks and continuously online image repositories, making them unsuitable for on-orbit satellites. The onboard environment faces constraints such as low satellite-to-ground link bandwidth, short transit windows, intermittent connections, and high error rates. When initiating an upgrade, a complete image often cannot be transmitted within a single window. Simultaneously, onboard computing, storage, and thermal control resources are limited, and the image uploading and reconstruction process may conflict with high-priority payload tasks, affecting the continuity of on-orbit services.

[0004] These factors can easily lead to a disconnect between the transmission, restoration, and upgrade deployment phases. Existing technologies struggle to address issues such as managing the correlation between multiple service versions, on-board resource awareness and scheduling, and service upgrade switching under unstable links. Existing technologies have at least the following shortcomings: the ground-based OTA server and the onboard server lack a unified management model and linkage mechanism for containerized multi-service image versions, service orchestration versions, and configuration versions; when onboard service containers are created or upgraded and restarted, repeatedly pulling complete images from the ground excessively consumes scarce space-to-ground link resources; the upgrade process is highly coupled with the image transmission process, and link interruptions can easily lead to upgrade failures; the onboard system lacks an upgrade gating mechanism based on the current task load and resource status, making it difficult to ensure the normal operation of high-priority payload tasks; verification and rollback only cover binary file packages, failing to simultaneously cover image digests, Docker Compose orchestration, configuration versions, and business health status, making it difficult to achieve closed-loop version consistency among multiple services. Summary of the Invention

[0005] The following description illustrates the contributions made by this invention.

[0006] To address the aforementioned issues, this invention provides an OTA upgrade method for a satellite-borne computing platform, resolving problems related to multi-service version correlation management, on-board resource awareness and scheduling, and service upgrade switching under unstable links.

[0007] An OTA upgrade method for a satellite-borne computing platform includes the following steps: Upon receiving the upgrade command, an image differential package is generated based on the current original on-orbit image and the target image. At the same time, a Docker Compose change package and a unified upgrade list bound to the target image are generated and signed with a ground private key. Differential data, compose.yml change information, configuration change information, and signature list are transmitted via satellite-to-ground link. The image differential package includes the differential data, the Docker Compose change package includes the compose.yml change information and configuration change information, and the unified upgrade list includes the signature list. The onboard OTA Agent receives differential data, compose.yml change information, configuration change information, and signature list in a fragmented manner, and verifies the signatures; After all fragments are received, the unified upgrade manifest signature is verified using the pre-set public key, and the fragment hash value, the local storage original on-orbit image digest, the current compose.yml digest, configuration version and dependency version are verified. If the verification is successful, resource-aware image differential restoration is performed and the target image is restored based on the original on-orbit image. After the target image generated by the restoration is verified again by Digest, it is pushed to the onboard local registry. The local registry retains both the current stable version and the target version on a microservice basis. Select the security upgrade window, and the onboard Compose upgrade control module will pull the target image from the local registry for upgrade.

[0008] This invention also provides an OTA upgrade system for a satellite-borne computing platform, comprising a ground OTA management platform, a satellite-to-ground link, and a satellite-borne computing platform, characterized in that... The ground OTA management platform includes a Docker image Registry module, a Compose service configuration center module, a ground package generation and signing module, and a unified upgrade list module. The Docker image Registry module is used to store the current original on-orbit image and the target image. After receiving the upgrade command, the ground package generation and signing module generates an image differential package based on the current original on-orbit image and the target image. The Compose service configuration center module and the unified upgrade list module are used to generate Docker Compose change packages and unified upgrade lists bound to the target image, respectively. The satellite-to-ground link is used to transmit differential data, compose.yml change information, configuration change information, and a signature list. The image differential package includes the differential data, the Docker Compose change package includes the compose.yml change information and configuration change information, and the unified upgrade list includes the signature list; and The satellite-borne computing platform includes an onboard OTA Agent, Docker Compose upgrade control, an image differential restoration engine, an onboard local registry, and an onboard containerized service switching module. The onboard OTA Agent receives differential data, compose.yml change information, configuration change information, and a signature list, and verifies the signatures. The image differential restoration engine performs resource-aware image differential restoration and restores the target image based on the original on-orbit image. The onboard local registry stores the restored target version information. The Docker Compose upgrade control selects a safe upgrade window to pull the target image from the local registry. The onboard containerized service switching module performs stop, rebuild, and start operations according to service dependencies within the safe upgrade window. Each service pulls an image from the onboard local registry for version upgrade switching.

[0009] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the OTA upgrade method for the satellite-borne computing platform described above.

[0010] This invention discloses an OTA upgrade method, system, and computer storage medium for a satellite-borne computing platform. By constructing a closed-loop space-ground collaboration driven by a unified upgrade list, it establishes a mutually constraining and feedback-based collaborative relationship among ground version baselines, link fragmentation scheduling, on-board resource gating, on-board registry, and Docker Compose service switching. This enables verifiable, pauseable, and rollback upgrades of containerized versions of multiple services during the upgrade process, even under conditions of weak space-ground links and limited resources. Compared with existing technologies, this invention has at least the following breakthroughs: it achieves integrated OTA management including Docker image versions and Docker Compose service list versions, solving the problem that traditional OTA servers cannot manage containerized multi-service versions; it builds a Docker Registry locally on the on-board computing platform, solving the problem of needing to pull images from a remote ground location during satellite upgrades; it decouples the image transmission phase from the local service version upgrade switching phase, allowing images to be verified and pre-configured on-board before service upgrades are performed at an opportune time; it prevents the upgrade process from affecting high-priority satellite operations and payload tasks through on-board resource gating; and it ensures rapid rollback in case of upgrade failure through the on-board local registry and dual-version retention mechanism.

[0011] Other features and advantages of the invention will become more apparent from the following more detailed description, taken in conjunction with the accompanying drawings, which illustrate the advantages of the invention by way of example. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the OTA upgrade system of a satellite-borne computing platform according to one embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a ground-based OTA management platform according to one embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of the satellite-borne computing platform according to one embodiment of the present invention; and Figure 4 This is a schematic diagram of the OTA upgrade method for a satellite-borne computing platform according to one embodiment of the present invention. Detailed Implementation

[0013] The accompanying drawings illustrate the invention. Various embodiments are disclosed herein. Numerous specific details are set forth in the following description to provide a more thorough understanding of the invention. However, those skilled in the art will recognize that the technical content described herein can be practiced without one or more specific details, or other methods, components, materials, etc. In other examples, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring specific content.

[0014] Please refer to Figures 1-3 In one embodiment, the present invention provides an OTA upgrade system for a satellite-borne computing platform, comprising a ground OTA management platform 100, a satellite-to-ground link 200, and a satellite-borne computing platform 300. The ground OTA management platform 100 includes a Docker image Registry module 120, a Compose service configuration center module 130, a ground package generation and signing module 140, and a unified upgrade list module 150. The Docker image Registry module 120 is used to store the current on-orbit image v1 and the target image v2. After receiving an upgrade command, the ground package generation and signing module 140 generates an image differential package based on the current on-orbit image v1 and the target image v2. The Compose service configuration center module 130 and the unified upgrade list module 150 are respectively used to generate a Docker Compose change package bound to the target image and a unified upgrade list.

[0015] The satellite-to-ground link 200 is used to transmit differential data, compose.yml change information, configuration change information, and signature list. The image differential package includes the differential data, the Docker Compose change package includes the compose.yml change information and configuration change information, and the unified upgrade list includes the signature list.

[0016] The satellite-borne computing platform includes an onboard OTA Agent 310, a Docker Compose upgrade control 320, an image differential restoration engine 340, an onboard local registry 350, and an onboard containerized service switching module 360. The onboard OTA Agent 310 is used to receive differential data, compose.yml change information, configuration change information, and signature list, and verify the signatures. The image differential restoration engine 340 performs resource-aware image differential restoration and restores the v2 image based on v1. The onboard local registry 350 is used to store the restored target version V2. The Docker Compose upgrade control 320 is used to select a secure upgrade window to pull the V2 image from the local registry. The onboard containerized service switching module 360 ​​is used to perform stop, rebuild, and start operations in the order of service dependencies within the secure upgrade window. Each service pulls the image from the onboard local registry 350 for version upgrade switching.

[0017] The ground-based OTA management platform also includes a version baseline management module 110, and / or a rollback strategy and decision center module 160, and / or a link scheduling module 170. The version baseline management module 110 manages the version baseline table, which records at least the service name, current image tag and digest, target image tag and digest, compose.yml version, environment variable version, mount directory version, port mapping version, dependent service version, rollback version, and upgrade priority. The rollback strategy and decision center module 160 stores rollback strategy information, which is also written into the unified upgrade list. The link scheduling module 170 adjusts the transmission strategy, determining the granularity and order of fragments to be sent based on the remaining duration of the telemetry and control window, link rate, bit error rate, and the received fragment bitmap on the satellite. Each fragment includes a number, offset, length, and hash value. After a link interruption, only the missing fragments are resumed. If the onboard resource gating detects a high-priority task or exceeds temperature limits, it can notify the ground to suspend transmission or reduce the transmission rate. Differential packets can be transmitted in tiers and fragments based on service priority, image layer dependencies, upgrade urgency, and remaining time in the monitoring and control window. Fields such as service priority, fragment priority, dependency layer identifier, and whether a fragment is critical for startup can be added to the fragment metadata.

[0018] The satellite-borne computing platform also includes an onboard resource gating system 330 and / or an OTA status feedback module 370. The onboard resource gating system 330 is used to set gating conditions, which refer to the set of resources and task states allowed to enter the reception, restoration, or deployment phases on the satellite. CPU, memory, storage, I / O, temperature, power status, payload task status, and remaining time in the telemetry and control window are all included in the gating, but with different weights at different stages. The gating results can be transmitted back to the ground via telemetry, allowing the link scheduling module to dynamically adjust the transmission strategy.

[0019] The OTA status feedback module 370 is used to perform health checks, comprehensively evaluating container running status, service heartbeat, business interface response, log anomalies, and resource consumption curves. If the check results meet preset indicators, v2 is solidified as a new stable baseline, and the success result, new version digest, service startup time, and health check data are sent back to the ground OTA management platform, which updates the version baseline record accordingly. If the health check fails, the Docker Compose upgrade control module 320 restores the previous version's compose.yml and configuration, and pulls the v1 stable image from the local Registry 350 to complete the rollback. The failed service, failure reason, rollback result, and resource curves are sent back to the ground for diagnosis and subsequent decision-making.

[0020] Please refer to Figure 4 The OTA upgrade method for the spaceborne computing platform of the present invention includes the following steps: Step S1: Maintain the version baseline and perform a consistency check.

[0021] The ground-based containerized OTA management platform maintains a version baseline table, recording the service name, current image tag and digest, target image tag and digest, compose.yml version, environment variable version, mount directory version, port mapping version, dependent service version, rollback version, and upgrade priority. When an upgrade is triggered, it first verifies whether the image digest referenced in compose.yml is consistent with the target image digest; if they are inconsistent, the upgrade task is rejected.

[0022] Step S2: Generate the image differential package, Compose change package, and collaborative upgrade list.

[0023] The ground-based package generation and signing module obtains the on-orbit baseline version v1 and the target version v2, generates image differential packages based on image layers or OCI image layouts, and simultaneously generates Docker Compose change packages. Subsequently, the target image digest, compose.yml digest, configuration digest, shard index, differential algorithm, target satellite identifier, resource requirements, rollback strategy, and signature information are written into the collaborative upgrade list and signed with a ground private key.

[0024] Step S3: Collect on-board resources and perform phase gating.

[0025] The onboard OTA agent, in collaboration with the onboard resource gating module, collects data on CPU, memory, storage, I / O, temperature, power status, payload task priority, and remaining time in the telemetry and control window to determine whether to allow entry into the receiving, restoration, or deployment phase. The gating results are transmitted back to the ground along with the telemetry data, allowing the link scheduling module to adjust transmission strategies.

[0026] For example, the following conditions must be met: overall CPU utilization is below 60%, available memory is greater than 1GB, remaining storage in the target working area is greater than twice the differential packet size with at least 500MB of safety margin, disk I / O utilization is below 50%, critical equipment temperature is below 65 degrees Celsius, power supply is stable, no P0-level payload tasks are currently running, and the remaining time in the telemetry and control window is greater than the expected reception time plus a 5-minute safety margin. If these conditions are met, the reception or restoration phase can proceed; if the temperature rises or a P0 task begins, the process should be paused or slowed down.

[0027] Step S4: Perform reliable fragmented transmission on weak links.

[0028] The ground link scheduling module determines the granularity and order of fragments to be transmitted based on the remaining duration of the telemetry and control window, link rate, bit error rate, and the received fragment bitmap on the satellite. Each fragment includes a number, offset, length, and hash value; if the link is interrupted, only the missing fragments are resumed. If the satellite resource gating detects a high-priority task or exceeds the temperature limit, it can notify the ground to suspend transmission or reduce the transmission rate.

[0029] Differential packets can be transmitted in tiers and fragments based on service priority, image layer dependencies, upgrade urgency, and remaining time in the monitoring and control window. Fields such as service priority, fragment priority, dependency layer identifier, and whether a fragment is critical for startup can be added to the fragment metadata.

[0030] For example, differential fragments of attitude and orbit control support services, payload mission scheduling services, or safety repair services are marked with P0 / P1 priority. The ground link scheduling module prioritizes sending the base layer differential, configuration changes, and startup-required layers for these services within a short window; fragments of low-priority log collection, non-critical visualization, or batch processing services can be postponed to subsequent windows. If the link is interrupted, the satellite transmits the missing P0 / P1 fragments back based on the received fragment bitmap, and the ground prioritizes retransmission to ensure that high-priority services have the conditions for restoration and upgrade first.

[0031] Step S5: Perform on-board step-by-step verification.

[0032] Upon receipt, the onboard OTA Agent uses a pre-configured public key to verify the upgrade manifest signature and checks the shard hash, local v1 image digest, current compose.yml digest, configuration version, and dependency versions. If any verification fails, image restoration is not triggered.

[0033] These verification items cover transport integrity, task authenticity, differential baseline consistency, orchestration consistency, configuration consistency, and service dependency consistency. Failure in any one of these items may result in the differential not being able to be restored, mismatch between the image and orchestration, or abnormal operation of the service after startup; therefore, the restoration phase should not be initiated.

[0034] In another implementation, to further improve reliability, the following can also be verified: the target image v2's Digest and OCI manifest digests, image layer Digest, differential algorithm version, differential packet size and total number of fragments, target satellite identifier, upgrade task number, anti-replay timestamp or sequence number, certificate validity, Compose syntax validity, environment variable whitelist, port conflicts, mount path permissions, existence of rollback version, and completeness of health check scripts or probe definitions. For high-security scenarios, verification of image vulnerability scan results, SBOM digest, and signature certificate chain can also be added.

[0035] Step S6: Perform resource-aware image differential restoration.

[0036] The differential restore engine reads the local v1 image or OCI layout from the temporary workspace and restores the v2 image based on the differential package. The restore process is constrained by CPU share, memory limit, I / O rate, and temperature threshold. If a high-priority task is detected, the restore is paused or the restore rate is reduced, automatically resuming once resources are available. Resource limits are configured for the restore engine in the upgrade manifest. For example: the CPU share of the differential restore container is limited to 1 core or 25% of the total CPU; the memory limit is 768MB; the temporary workspace I / O write rate is limited to 20MB / s; the device temperature warning threshold is 65 degrees Celsius, and the pause threshold is 70 degrees Celsius; the restore stops and an alarm is triggered when the remaining system storage falls below 800MB.

[0037] If a high-priority payload task is detected to be starting during operation, such as real-time imaging compression or inter-satellite routing tasks, the gating module can reduce the CPU share of restoration from 25% to 10% and the I / O speed limit from 20MB / s to 5MB / s. If the CPU usage continues to exceed 80% or the temperature reaches 70 degrees Celsius, restoration will be paused and a checkpoint will be saved. Restoration will continue after the payload task ends, the CPU usage drops below 60%, and the temperature drops below 65 degrees Celsius.

[0038] Step S7: Push the onboard local registry.

[0039] Step S8: Select the security upgrade window.

[0040] A security escalation window refers to a period of time or state condition during which onboard services can be stopped, rebuilt, and restarted without affecting critical onboard missions or high-priority payloads. It is not necessarily a fixed time period; it can also be an escalable state determined by a combination of mission status, resource status, link status, and rollback conditions.

[0041] For example: the satellite is not in a critical telemetry and control command execution period; no P0 / P1 payload missions are running; the current service has redundant instances or short downtime is acceptable; CPU, memory, I / O, and temperature are within thresholds; both v1 and v2 images are available in the local registry; rollback of compose.yml and configuration are ready; the expected service rebuild time is less than the allowable downtime. When these conditions are met, upgrade actions can be planned in the order of dependencies.

[0042] Step S9: Perform a local upgrade using Docker Compose.

[0043] Within the preset security upgrade window, the Docker Compose upgrade control module performs stop, rebuild, and start operations in the order of service dependencies. Each service pulls images from the onboard local registry, and the service switchover phase does not rely on a real-time connection between the satellite and ground links.

[0044] Step S10: Perform a closed loop of health check, rollback, and status feedback.

[0045] After the upgrade is complete, the system checks the container running status, service heartbeat, business interface response, log anomalies, and resource consumption curves. If the check is successful, v2 is solidified as the new stable baseline, and the success result, new version digest, service startup time, and health check data are transmitted back. If the check fails, the previous version's compose.yml and configuration are restored, and the v1 stable image is pulled from the local Registry to complete the rollback. At the same time, the failed service, the reason for the failure, the rollback result, and the resource curves are transmitted back.

[0046] Through the above implementation methods, the present invention realizes an integrated closed loop of containerized version management, reliable transmission over weak links, on-board image restoration, on-board local image publishing, and Docker Compose multi-service switching within the onboard containerized computing platform.

[0047] Throughout this specification, references to "an embodiment," "an example," or "an example" mean that a particular feature, structure, or characteristic described in connection with that embodiment or example is included in at least one embodiment. Or, an example of the invention. Therefore, phrases such as "in one embodiment" or "in one example" appearing throughout this specification do not necessarily refer to the same embodiment or example. Furthermore, a particular feature, structure, or characteristic may be combined in any suitable manner in one or more embodiments or examples. Directional terms such as "top," "down," "above," and "below" are used to indicate the direction of reference to the described drawings. Furthermore, unless otherwise specifically stated, the terms "having," "comprising," "containing," and similar terms are defined as meaning "including." A particular feature, structure, or characteristic may be included in an integrated circuit, electronic circuit, combinational logic circuit, or other suitable component that provides the described functionality. Additionally, it should be understood that the drawings provided herein are for illustrative purposes only and are not necessarily drawn to scale.

[0048] The above description of the illustrated examples of the invention (including those described in the abstract) is not intended to be exhaustive or limited to the precise forms disclosed. While specific embodiments and examples of the invention have been described herein for illustrative purposes, various equivalent modifications may be made without departing from the broader spirit and scope of the invention. Indeed, it should be understood that specific example structures and materials are provided for illustrative purposes, and other structures and materials may be used in other embodiments and examples based on the teachings of the invention. These modifications can be made to embodiments of the invention based on the above detailed description. The terminology used in the following claims should not be construed as limiting the invention to the specific embodiments disclosed in the specification and claims. Rather, the scope is determined entirely by the following claims, which should be interpreted according to the established principles of their interpretation.

Claims

1. An OTA upgrade method for a satellite-borne computing platform, characterized in that, Includes the following steps: Upon receiving the upgrade command, an image differential package is generated based on the current original on-orbit image and the target image. At the same time, a Docker Compose change package and a unified upgrade list bound to the target image are generated and signed with a ground private key. Differential data, compose.yml change information, configuration change information, and signature list are transmitted via satellite-to-ground link. The image differential package includes the differential data, the Docker Compose change package includes the compose.yml change information and configuration change information, and the unified upgrade list includes the signature list. The onboard OTA Agent receives differential data, compose.yml change information, configuration change information, and signature list in a fragmented manner, and verifies the signatures; After all fragments are received, the unified upgrade manifest signature is verified using the pre-set public key, and the fragment hash value, the local storage original on-orbit image digest, the current compose.yml digest, configuration version and dependency version are verified. If the verification is successful, resource-aware image differential restoration is performed and the target image is restored based on the original on-orbit image. After the target image generated by the restoration is verified again by Digest, it is pushed to the onboard local registry. The local registry retains both the current stable version and the target version on a microservice basis. Select the security upgrade window, and the onboard Compose upgrade control module will pull the target image from the local registry for upgrade.

2. The method as described in claim 1, characterized in that, The Docker Compose change package should include at least the target compose.yml or a difference patch relative to the current compose.yml; the target service name; the local registry address, tag, and digest of the target image; environment variables and configuration file versions; port mappings; mount directories; and service dependencies. Startup order; Restart strategy; CPU / memory limits; health check parameters; necessary rollback compose.yml or rollback configuration references, and / or, the upgrade manifest includes at least: target satellite identifier, upgrade task number, baseline version information, target version information, current image digest, target image digest, image layer digest or OCI layer digest, differential algorithm, shard index, number / offset / length / hash of each shard, Docker Compose change package digest, configuration digest, dependency version, resource gating threshold, upgrade priority, security upgrade window, rollback strategy, signature algorithm, signature value, and public key / certificate reference.

3. The method as described in claim 1, characterized in that, Based on the remaining duration of the telemetry and control window, the link rate, the bit error rate, and the received fragment bitmap on the satellite, the granularity and order of the fragments to be sent are determined. Each fragment contains a number, offset, length, and hash value. After a link is interrupted, only the missing fragments are resumed; if the onboard resource gating detects a high-priority task or exceeds the temperature limit, it notifies the ground to suspend transmission or reduce the transmission rate.

4. The method as described in claim 1, characterized in that, The image layer differential packets are transmitted in a hierarchical and fragmented manner according to service priority, image layer dependency, upgrade urgency and remaining time of the monitoring and control window. The fragment metadata adds fields for service priority, fragment priority, dependency layer identifier and whether the fragment is critical to start.

5. The method as described in claim 1, characterized in that, The ground-based OTA management platform maintains a version baseline table, recording the service name, current image tag and digest, target image tag and digest, compose.yml version, environment variable version, mount directory version, port mapping version, dependent service version, rollback version, and upgrade priority. When an upgrade is triggered, the ground-based OTA management platform, upon receiving the upgrade command, also checks the digest of the target image. If they are inconsistent, the upgrade will not be initiated to generate the image package.

6. The method as described in claim 1, characterized in that, Before the satellite-to-ground link transmission, an onboard resource assessment is also performed. The onboard OTA Agent receives and verifies the fragments when the resource gating conditions are met. The gating conditions are the set of resources and task states that are allowed to enter the reception, restoration or deployment phase on the satellite. CPU, memory, storage, I / O, temperature, power status, payload task status and remaining time of the telemetry and control window are all included in the gating, with different weights for different phases.

7. The method as described in claim 1, characterized in that, When entering the transmission phase, the ground link scheduling module determines the granularity and order of the fragments to be sent based on the remaining duration of the current telemetry and control window, the link rate, the bit error rate, and the received fragment bitmap on the satellite, and works with the satellite OTA Agent to receive fragments and perform hash verification.

8. The method as described in claim 1, characterized in that, During the verification process after all fragments have been received, the following are further verified: target image digest and OCI manifest summary, image layer digest, differential algorithm version, differential packet size and total number of fragments, target satellite identifier, upgrade task number, anti-replay timestamp or sequence number, certificate validity period, Compose syntax validity, environment variable whitelist, port conflict, mount path permissions, existence of rollback version, and whether the health check script or probe definition is complete.

9. The method as described in claim 1, characterized in that, Further verification is performed on the image vulnerability scan result summary, SBOM summary, and signature certificate chain.

10. The method as described in claim 1, characterized in that, Before transmission, change the repository address via the ground management platform; or, before local upgrade, change the image's repository address via satellite.

11. The method as described in claim 1, characterized in that, The unified upgrade list simultaneously carries constraints on image digest, OCI layer digest, compose digest, differential block hash, and resource gating threshold. After receiving the differential data, the satellite performs step-by-step verification based on the signature and fragment hash in the upgrade list. At the same time, it checks whether the information such as the original on-orbit image digest, compose.yml digest, and configuration version stored locally is consistent with the baseline recorded in the list. If any verification fails, image restoration is not triggered.

12. The method as described in claim 1, characterized in that, After verification, the image differential restoration engine performs image restoration in the temporary workspace. The restoration process is subject to real-time control of resource gating, including CPU share, memory limit, I / O rate and temperature threshold, all of which are limited according to the constraints marked in the upgrade list.

13. The method as described in claim 1, characterized in that, The Docker Compose upgrade control module selects a safe upgrade window based on conditions such as satellite status, resource status, and link status. Within the preset safe upgrade window, it performs stop, rebuild, and start operations in the order of service dependencies. Each service pulls images from the onboard local registry, and the entire service switching process does not require a real-time connection between the satellite and the ground link.

14. The method as described in claim 1, characterized in that, After the upgrade, the following steps are also included: After the upgrade is completed, a health check is performed. The satellite checks the container running status, service heartbeat, business interface response, log anomalies, and resource consumption curves. If the check is successful, the target version information is solidified into a new stable baseline, and the success result, new version digest, service startup time, and health check data are sent back. If the check fails, the previous version's compose.yml and configuration are restored, and the original on-orbit image is pulled from the local Registry to complete the rollback. At the same time, the failed service, failure reason, rollback result, and resource curves are sent back.

15. An OTA upgrade system for a satellite-borne computing platform, comprising a ground OTA management platform, a satellite-to-ground link, and a satellite-borne computing platform, characterized in that, The ground-based OTA management platform includes a Docker image registry module, a Compose service configuration center module, a ground-based package creation and signing module, and a unified upgrade list module; The Docker image Registry module is used to store the current original on-orbit image and the target image. After receiving the upgrade instruction, the ground package generation and signing module generates an image differential package based on the current original on-orbit image and the target image. The Compose service configuration center module and the unified upgrade list module are used to generate Docker Compose change packages and unified upgrade lists bound to the target image, respectively. The satellite-to-ground link is used to transmit differential data, compose.yml change information, configuration change information, and a signature list. The image differential package includes the differential data, the Docker Compose change package includes the compose.yml change information and configuration change information, and the unified upgrade list includes the signature list; and The satellite-borne computing platform includes an onboard OTA Agent, Docker Compose upgrade control, an image differential restoration engine, an onboard local registry, and an onboard containerized service switching module. The onboard OTA Agent receives differential data, compose.yml change information, configuration change information, and a signature list, and verifies the signatures. The image differential restoration engine performs resource-aware image differential restoration and restores the target image based on the original on-orbit image. The onboard local registry stores the restored target version information. The Docker Compose upgrade control selects a safe upgrade window to pull the target image from the local registry. The onboard containerized service switching module performs stop, rebuild, and start operations according to service dependency order within the safe upgrade window. Each service pulls an image from the onboard local registry for version upgrade switching.

16. The system as claimed in claim 12, characterized in that, The ground-based OTA management platform also includes a version baseline management module, and / or a rollback strategy and decision center module, and / or a link scheduling module; The version baseline management module is used to manage the version baseline table, which records at least the service name, current image tag and digest, target image tag and digest, compose.yml version, environment variable version, mount directory version, port mapping version, dependent service version, rollback version, and upgrade priority. The rollback strategy and decision center module is used to store rollback strategy information and is written together into the unified upgrade list; The link scheduling module is used to adjust the transmission strategy. Based on the remaining duration of the telemetry and control window, the link rate, the bit error rate, and the received fragment bitmap on the satellite, it determines the granularity and order of the fragments to be sent. Each fragment contains a number, offset, length, and hash value.

17. The system as claimed in claim 12, characterized in that, The satellite-borne computing platform also includes onboard resource gating and / or an OTA status feedback module; wherein The onboard resource gating is used to set gating conditions. The gating conditions refer to the set of resources and mission states that are allowed to enter the receiving, restoration or deployment phase on the satellite. CPU, memory, storage, I / O, temperature, power status, payload mission status and remaining time of the telemetry and control window are all included in the gating, with different weights for different phases. The OTA status feedback module is used to perform health checks and comprehensively evaluate container running status, service heartbeat, business interface response, log anomalies, and resource consumption curves.

18. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 14.

Images