On-orbit reconfiguration method, system and device based on zynq platform

Abstract

The application discloses an on-orbit reconfiguration method, system and device based on a ZYNQ platform, and the method comprises upgrade reconfiguration and maintenance reconfiguration; the upgrade reconfiguration is performed by injecting reconfiguration instructions and data packets to the ZYNQ platform from the ground, the reconfiguration is executed by the ZYNQ platform, and after completion, the reconfiguration is checked; if the checking is wrong, the data packets are re-injected from the ground; the maintenance reconfiguration is performed by storing backup data packets on the satellite, the reconfiguration is executed by the ZYNQ platform, and after completion, the reconfiguration is checked; if the checking is wrong, the backup data packets are switched to execute the reconfiguration; until the checking is correct or the checking is still wrong after all the backup data packets are executed, the data packets are injected from the ground; the upgrade reconfiguration has a higher priority than the maintenance reconfiguration; after the ZYNQ platform executes the reconfiguration and the checking is correct, the data packets are injected from the ground to update the backup data packets. The application establishes a reconfiguration scheme applied to the ZYNQ platform in a systematic way, can realize reconfiguration management control of the ZYNQ under different task targets, and improves the reliability of the ZYNQ platform reconfiguration.

Description

Technical Field

[0001] This application relates to an on-orbit reconfiguration method, system, and device based on the ZYNQ platform for use in the field of space electronic control. Background Technology

[0002] As spacecraft missions become increasingly complex, higher demands are being placed on the performance, integration, and reliability of computing platforms. Xilinx's ZYNQ platform, as a heterogeneous computing platform integrating a processing system (PS) and programmable logic (PL), offers advantages such as high integration, low power consumption, and flexible reconfigurability, gradually becoming an important choice for on-orbit computing missions in spacecraft. However, practical experience with on-orbit applications of the Zynq platform is limited, especially in the complex space environment, where its startup and reconfiguration processes face numerous challenges.

[0003] The ZYNQ platform startup process consists of two phases: first, the PS (Power System) component needs to be booted, followed by the PL (Power Process) component. In an on-orbit environment, the ZYNQ startup and operation may be affected by factors such as radiation and temperature changes, leading to PS boot failure or PL crashes, requiring platform recovery through refactoring. Conventional refactoring techniques execute refactoring tasks on a single PS or PL objective, lacking a systematic management method for the ZYNQ platform refactoring process. This makes refactoring tasks prone to conflicts in complex application scenarios, causing system chaos and affecting refactoring execution. Furthermore, under extreme conditions such as solar storms, the ZYNQ platform's on-orbit redundant resources may be exhausted, leading to refactoring failure. Summary of the Invention

[0004] The purpose of this application is to overcome the shortcomings of the prior art and provide an on-orbit reconfiguration method, system and device based on the ZYNQ platform. By establishing a systematic reconfiguration scheme applied to the ZYNQ platform, it is possible to realize the reconfiguration management and control of ZYNQ under different mission objectives and improve the reliability of ZYNQ platform reconfiguration.

[0005] Firstly, this application provides an on-orbit reconfiguration method based on the ZYNQ platform, which adopts the following technical solution:

[0006] For upgrade and reconstruction, the ground sends upgrade and reconstruction instructions and upgrade and reconstruction data packets to the ZYNQ platform. The ZYNQ platform executes the upgrade and reconstruction instructions and performs the reconstruction process through the upgrade and reconstruction data packets. After completion, reconstruction verification is performed. If the verification fails, an error signal is sent to the ground, and the ground sends upgrade and reconstruction data packets again to re-inject the upgrade and reconstruction process.

[0007] For maintenance and reconfiguration, at least two on-orbit maintenance and reconfiguration data packets that serve as backups for each other are stored in the on-orbit redundant memory. The ZYNQ platform executes the maintenance and reconfiguration process using one on-orbit maintenance and reconfiguration data packet based on the maintenance and reconfiguration command issued on-orbit. After completion, a reconfiguration verification is performed. If the verification fails, the other on-orbit maintenance and reconfiguration data packet is switched to execute the maintenance and reconfiguration process until the verification is successful or the verification still fails after executing all on-orbit maintenance and reconfiguration data packets. If the verification still fails, an error signal is sent to the ground, and the ground uplink injects a ground maintenance and reconfiguration data packet to execute the reconfiguration process.

[0008] During the execution of upgrade and refactoring instructions, maintenance and refactoring instructions are not executed; during the execution of maintenance and refactoring instructions, if an upgrade and refactoring instruction is received, the execution of maintenance and refactoring instructions is stopped, and upgrade and refactoring instructions are executed instead.

[0009] For upgrade and reconfiguration data packets or ground maintenance reconfiguration data packets injected from the ground uplink, once the ZYNQ platform executes the reconfiguration process and verifies its correctness, it updates the on-orbit maintenance reconfiguration data packets using the upgrade and reconfiguration data packets or ground maintenance reconfiguration data packets.

[0010] By adopting the above technical solution, on-orbit reconfiguration is divided into ground-led upgrade reconfiguration and on-orbit control-led maintenance reconfiguration. Upgrade reconfiguration involves ground-based on-orbit software upgrades to the ZYNQ platform, achieved by sending upgrade commands and upgrade reconfiguration packages from the ground. Maintenance reconfiguration is controlled by maintenance commands issued by the on-orbit control system, primarily through redundant images configured on the on-orbit backup ZYNQ. Ground assistance is only requested when redundant resources are exhausted. Ground commands have the highest priority and are executed first to prevent command conflicts during reconfiguration, which could lead to the occupation of ZYNQ platform channels and other system resources, affecting the normal progress of reconfiguration. Uplinked upgrade reconfiguration data packets or ground maintenance reconfiguration data packets from the ground update the on-orbit maintenance reconfiguration data packets to ensure that subsequent maintenance does not require ground intervention, reducing reliance on the ground.

[0011] Preferably, the upgrade reconstruction data packet or the ground maintenance reconstruction data packet includes PS data packets and PL data packets. First, the PS unit of the ZYNQ platform is reconstructed through PS data packets. After completion, the PS unit is reconstructed and verified. If the verification fails, PS data packets are re-injected from the ground and reconstructed. If the verification is successful, the PL unit of the ZYNQ platform is reconstructed through PL data packets. After completion, the PL unit is reconstructed and verified. If the verification fails, PL data packets are re-injected from the ground.

[0012] Preferably, the PS data packet and the PL data packet are stored in different storage modules.

[0013] The above technical solution divides the upgrade reconstruction data packet or the ground maintenance reconstruction data packet into PS data packets and PL data packets according to the object of reconstruction, and divides the reconstruction process into stages, performing PS stage reconstruction and PL stage reconstruction sequentially. Upon completion of each stage, a verification is performed. If a verification error is found, an uplink injection request is re-requested according to the data packet type. This technical solution decomposes the reconstruction process, ensuring the effective progress of the reconstruction process, reducing the total workload of verification and repair when errors occur, and improving reconstruction efficiency.

[0014] Preferably, the on-orbit maintenance reconfiguration data packets for different items are stored in different partitions within the storage module.

[0015] Preferably, for any on-orbit maintenance reconfiguration data packet, if the reconfiguration process performed by it fails the verification after reconfiguration, it is marked. After the reconfiguration process is completed, the on-orbit maintenance reconfiguration data packet is updated based on the on-orbit maintenance reconfiguration data packet or the ground maintenance reconfiguration data packet that has been verified correctly.

[0016] The above technical solution enables redundant backup of on-orbit maintenance reconfiguration data packets, preventing individual on-orbit maintenance reconfiguration data packets from being damaged by radiation. After reconfiguration, on-orbit maintenance reconfiguration data packets with verification errors are updated, preparing for subsequent system reconfiguration and backup, and further improving system reliability and reducing dependence on the ground.

[0017] Secondly, this application provides an on-orbit reconfiguration system based on the ZYNQ platform, which adopts the following technical solution:

[0018] The on-orbit reconfiguration system includes a reconfiguration module, a ZYNQ platform, and an on-orbit storage module;

[0019] The reconfiguration module includes a reconfiguration storage submodule and a reconfiguration command submodule. The reconfiguration command submodule is connected to the ZYNQ platform. It receives and parses upgrade reconfiguration commands injected from the ground uplink or maintenance reconfiguration commands issued in orbit, and sends the parsed upgrade reconfiguration commands or maintenance reconfiguration commands to the ZYNQ platform. The reconfiguration storage submodule stores the upgrade reconfiguration data packets or ground maintenance reconfiguration data packets injected from the ground uplink.

[0020] The ZYNQ platform receives parsed upgrade / reconstruction or maintenance / reconstruction commands. If it is an upgrade / reconstruction command, it reads the upgrade / reconstruction data packet from the reconstruction storage submodule, executes the reconstruction process, and performs reconstruction verification. If it is a maintenance / reconstruction command, it reads one on-orbit maintenance / reconstruction data packet from the on-orbit storage module, executes the reconstruction process, and performs reconstruction verification. If the verification fails, it reads another on-orbit maintenance / reconstruction data packet. If the verification still fails after reading all on-orbit maintenance / reconstruction data packets and executing the reconstruction process, it reads the ground maintenance / reconstruction data packet from the reconstruction storage submodule and executes the reconstruction process.

[0021] The on-orbit storage module is partitioned, and several on-orbit maintenance and reconstruction data packets are stored in different partitions of the on-orbit storage module.

[0022] The above technical solution provides a system adapted to the on-orbit reconfiguration method based on the ZYNQ platform. The reconfiguration module parses and outputs reconfiguration instructions, ensuring the smooth execution of the on-orbit reconfiguration method and avoiding single points of failure caused by ZYNQ platform boot errors that make it difficult to execute reconfiguration instructions. The ZYNQ platform executes the target reconfiguration task according to the received instructions and reads the reconfiguration data packet in the corresponding memory, realizing data isolation and fast retrieval, and improving the system's anti-interference and loading efficiency.

[0023] Preferably, the reconfigurable storage submodule includes a PS storage unit and a PL storage unit, wherein the PS storage unit uses a QSPI FLASH memory and the PL storage unit uses an SPI NAND Flash memory.

[0024] Preferably, the on-orbit storage module includes an on-orbit PS storage section and an on-orbit PL storage section. The on-orbit PS storage section uses MRAM memory, and the PS boot files of different on-orbit maintenance and reconstruction data packets are stored in different partitions of the MRAM memory. The on-orbit PL storage section uses eMMC memory, and the PL bit streams of different on-orbit maintenance and reconstruction data packets are stored in different partitions of the eMMC memory.

[0025] The above technical solution provides a memory type that adapts to different reconstruction task objectives and data storage requirements, ensuring that reconstruction data packets are stored and retrieved on demand, achieving redundant data storage and backup, and optimizing the reconstruction system.

[0026] Thirdly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described on-orbit reconfiguration method based on the ZYNQ platform.

[0027] In summary, this application includes at least one of the following beneficial technical effects:

[0028] 1. This application provides an on-orbit reconfiguration method based on the ZYNQ platform, which incorporates ground-led upgrade reconfiguration and on-orbit-led maintenance reconfiguration into a systematic reconfiguration process, rather than being limited to reconfiguration processes for single tasks (such as reconfiguration triggered by single-event upsets (SEUs). This makes the reconfiguration process clear and smooth, highly scalable, and reduces interference with reconfiguration reliability caused by process issues of different reconfiguration tasks.

[0029] 2. For reconstruction processes that fail to verify errors and cannot be corrected using on-orbit data, this application injects a reconstruction package via ground uplink, enabling auxiliary backup of on-orbit reconstruction from the ground and improving system reliability.

[0030] 3. This application divides the reconstruction process of the ZYNQ platform into stages based on the PS department and the PL department, and performs reconstruction and verification in stages. When a stage verification error occurs, the data in the storage area is called or injected uplink specifically for the reconstruction data packet of the current stage, which can improve the efficiency of data calling and avoid full uplink injection.

[0031] 4. The on-orbit reconfiguration system based on the ZYNQ platform in this application separates the control of reconfiguring the ZYNQ platform from ZYNQ and provides a separate reconfiguration module for parsing and controlling reconfiguration instructions, so as to avoid the system failing to start due to PS loading failure and causing a single point of failure. Attached Figure Description

[0032] Figure 1 This is a flowchart of the on-orbit reconfiguration method based on the ZYNQ platform in the embodiments of this application;

[0033] Figure 2 This is a flowchart of S100 in the embodiments of this application;

[0034] Figure 3 This is a flowchart of S120 in an embodiment of this application;

[0035] Figure 4 This is a flowchart of S200 in an embodiment of this application;

[0036] Figure 5 This is a structural block diagram of the on-orbit reconfiguration system based on the ZYNQ platform in the embodiments of this application;

[0037] Figure 6 This is an example diagram of a computer device in an embodiment of this application. Detailed Implementation

[0038] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0039] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. It should be noted that in the optional embodiments of this application, the object information and other related data involved require the permission or consent of the object when the embodiments of this application are applied to specific products or technologies, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. That is to say, if the embodiments of this application involve data related to the object, it needs to be obtained with the authorization and consent of the object, the authorization and consent of the relevant departments, and in compliance with the relevant laws, regulations, and standards of the country and region. If personal information is involved in the embodiments, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required, and the embodiments also need to be implemented with the authorization and consent of the object.

[0040] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0041] In one embodiment, please refer to Figure 1 This application discloses an on-orbit reconfiguration method based on the ZYNQ platform, which includes S100 upgrade reconfiguration, S200 maintenance reconfiguration, and S300 update on-orbit maintenance reconfiguration data packets.

[0042] S100 upgrade and reconfiguration refers to a situation where the ZYNQ platform's mission requirements exceed its preset and fault-tolerant range, making reconfiguration impossible through on-orbit redundant data. Instead, it is controlled by upgrade and reconfiguration commands issued from the ground and implemented through uplink injection of upgrade and reconfiguration data packets. Depending on the object of the reconfiguration, the specific scenarios for upgrade and reconfiguration include:

[0043] For PS reconstruction, upgrade reconstruction scenarios include: major software function upgrades, PS security vulnerability fixes, and PS adjustments to adapt to new PL hardware logic.

[0044] For PL refactoring, upgrade and refactoring scenarios include: upgrading the functionality of PL hardware modules, updating the hardware configuration parameters of PL, and switching dynamic tasks of PL.

[0045] Please see Figure 2 The specific steps for upgrading and reconstructing the S100 are as follows:

[0046] S110, which injects upgrade and reconfiguration commands and upgrade and reconfiguration data packets from the ground to the ZYNQ platform;

[0047] S120 is executed by the ZYNQ platform to carry out the upgrade and reconstruction command. The upgrade and reconstruction process is carried out through the upgrade and reconstruction data packet. After completion, the reconstruction verification is performed. If the verification fails, an error signal is sent to the ground and returned to S110, where the ground re-injects the upgrade and reconstruction data packet.

[0048] S130, if the verification is correct, the upgrade and reconstruction process is completed.

[0049] Specifically, the upgrade and reconstruction data package includes a PS data package and a PL data package. The PS and PL data packages are stored in different storage modules. For details, please refer to... Figure 3 S120 specifically refers to:

[0050] S121 reconstructs the PS unit of the ZYNQ platform according to the PS data packet, loads the pre-compiled FSBL into the specified address of the PS's DDR memory, calls u-boot to initialize the hardware, and transfers the image to DDR through u-boot;

[0051] S122, configure the PS interrupt register, load the reconstruction verification status of the correct or incorrect flag through PCAP, if the verification is incorrect, automatically roll back to the previous stable version, re-inject PS data packets from the ground, and return to S121;

[0052] S123, if the verification is correct, the PL section of the ZYNQ platform is reconstructed according to the PL data package, the PL bitstream data.bin of the PL data package is called, and the PCAP configuration process is started to write the bitstream data into the PL configuration area;

[0053] S124: Monitor whether the PCAP status register verification configuration is complete or abnormal. If PCAP loading failure or PL verification error is detected, automatically roll back to the previous stable version, re-inject PL data packets from the ground, and return to S123.

[0054] In another embodiment, the PS terminal is equipped with a watchdog timer. If the reconstruction completion signal is not received within the timeout period, the system is forcibly restarted, and the PS data packets and PL data packets are re-injected from the ground to re-execute the upgrade reconstruction process.

[0055] S200 maintenance and reconfiguration refers to the reconfiguration of the ZYNQ platform, controlled by maintenance and reconfiguration commands issued from in-orbit, without ground intervention, through in-orbit redundant backup data, utilizing on-orbit redundancy design, real-time monitoring, and pre-stored strategies to repair critical functions. Depending on the object of the reconfiguration, specific scenarios for upgrade reconfiguration include:

[0056] For PS refactoring, maintenance refactoring scenarios include: corruption of the master boot image (boot.bin) when PS is powered on or reset; PS application (such as attitude control algorithm) crashing due to memory errors or logical anomalies; and multi-bit EDAC errors caused by radiation in DDR memory.

[0057] For PL reconstruction, upgrade reconstruction scenarios include: high-energy particles causing a single-bit flip in the PL configuration memory (SRAM), resulting in abnormal logic function; changes in task requirements necessitating the loading of pre-stored PL modules; and PLs that cannot be repaired by erasure due to multi-frame errors, requiring global restoration to a known safe state.

[0058] Please see Figure 4 The specific steps for maintenance and reconstruction are as follows:

[0059] S210, the on-orbit control system sends a maintenance reconfiguration command to the ZYNQ platform;

[0060] S220 is executed by the ZYNQ platform using maintenance and reconfiguration commands. It performs the maintenance and reconfiguration process by executing an on-orbit maintenance and reconfiguration data packet stored in the on-orbit redundant memory. After completion, a reconfiguration verification is performed. If the verification fails, another on-orbit maintenance and reconfiguration data packet is switched to execute the reconfiguration process until the reconfiguration verification is successful or the verification still fails after executing all on-orbit maintenance and reconfiguration data packets. If the verification still fails, an error signal is sent to the ground, and the ground uplink injects a ground maintenance and reconfiguration data packet to re-execute S220.

[0061] S230, if the verification is correct, the maintenance and reconfiguration process is completed. For any on-orbit maintenance and reconfiguration data packet, if the reconfiguration process fails after verification, it is marked. After the reconfiguration is completed, the on-orbit maintenance and reconfiguration data packet is updated based on the verified on-orbit maintenance and reconfiguration data packet or the ground maintenance and reconfiguration data packet.

[0062] Specifically, the on-orbit maintenance reconfiguration data packets or ground maintenance reconfiguration data packets in S220 also include PS data packets and PL data packets. The specific steps of S220 can be implemented with reference to the specific steps of S120. The difference between S220 and S120 is that, for any verification error, the reconfiguration process is first performed by switching to another on-orbit maintenance reconfiguration data packet until the verification error still occurs after using all on-orbit maintenance reconfiguration data packets. Then, an error signal is sent, and the reconfiguration process is performed using the ground maintenance reconfiguration data packet injected via ground uplink. The on-orbit maintenance reconfiguration data packets of different items are stored in different storage locations. In one embodiment, for the on-orbit maintenance reconfiguration data packets, the PS data packet uses an MRAM memory. The MRAM memory is divided into a main storage unit sector and a redundant storage unit sector, which serve as backups for each other, and stores the BOOT.bin file of the on-orbit maintenance reconfiguration data packets of different items respectively. The PL data packet uses an eMMC memory. The eMMC memory is divided into a boot partition, a Boot1 partition, and a Boot2 partition. The boot partition is used to store the boot loader (U-Boot) and the image index table. The Boot1 partition and the Boot2 partition store different versions of the boot image respectively. Maintenance and refactoring are performed by calling the PS or PL data package according to the specific content of the maintenance and refactoring instructions.

[0063] In another embodiment, the uplink injection of upgrade and reconstruction data packets or ground maintenance and reconstruction data packets is used to transmit data from the ground station to the on-orbit spacecraft via the X-band link. Due to limitations in transmission link bandwidth and signal transmission window, performing phased verification and transmission of PS and PL data packets can improve the efficiency of uplink injection and ensure the success rate of data transmission tasks.

[0064] The on-orbit reconfiguration method based on the ZYNQ platform also includes updating the on-orbit maintenance reconfiguration data package via S300.

[0065] For upgrade and reconfiguration data packets or ground maintenance reconfiguration data packets injected from the ground uplink, once the ZYNQ platform executes the reconfiguration process and verifies its correctness, it updates the on-orbit maintenance reconfiguration data packets using the upgrade and reconfiguration data packets or ground maintenance reconfiguration data packets.

[0066] Furthermore, if the upgrade / reconstruction data package or the ground maintenance / reconstruction data package does not contain a PL data package, then when updating the on-orbit maintenance / reconstruction data package by updating the upgrade / reconstruction data package or the ground maintenance / reconstruction data package, the current PL configuration is used to update the PL data package of the on-orbit maintenance / reconstruction data package. For on-orbit reconstruction, whether PL reconstruction is needed after PS reconstruction depends on the functional coupling and scope of change between the two. When PS updates are independent of PL hardware functions, or only parameters are passed through an interface, synchronous PL reconstruction is not required, and therefore the upgrade / reconstruction data package or the ground maintenance / reconstruction data package will not contain a PL data package. In this case, backup updates are achieved by backing up the PL to the on-orbit maintenance / reconstruction data package, which avoids data decay caused by long-term silent storage and prevents reliability degradation.

[0067] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0068] To avoid conflicts in reconfiguration commands, system resources, including channels, are allocated appropriately. During the execution of upgrade reconfiguration commands, maintenance reconfiguration commands are not executed. If an upgrade reconfiguration command is received during the execution of maintenance reconfiguration commands, the execution of maintenance reconfiguration commands is stopped, and upgrade reconfiguration commands are executed instead.

[0069] Specifically, for the ZYNQ platform, upgrade / refactoring instructions are received via the AXI-GMAC interface, while maintenance / refactoring instructions are received via the PL-side SPI / UART interface, and written to separate DDR3 memory buffers. Based on the instruction type, the ZYNQ platform automatically assigns weight values: upgrade / refactoring instructions have a fixed weight of 25 (highest level), while maintenance / refactoring instructions have an initial weight of 10-20 (dynamically adjusted based on instruction type). A priority mapping table is implemented through the PL-side LUT, and updated in real-time to the instruction queue status register in BRAM (address offset 0x4000_1000). Refactoring instructions with higher weight values ​​are executed first. If an upgrade / refactoring instruction is received during the execution of maintenance / refactoring instructions, the on-orbit instruction execution thread is forcibly paused, and a snapshot of the current execution state is saved to the RPMB security partition of the eMMC via the AXI-HP interface.

[0070] In another embodiment, please refer to Figure 5 An on-orbit reconfiguration system based on the ZYNQ platform includes: a reconfiguration module 1, a ZYNQ platform 2, and an on-orbit storage module 3.

[0071] Reconstruction Module 1 is the actual control module for the reconstruction process. It receives and parses reconstruction commands, and then sends the parsed commands to the ZYNQ platform. It operates independently of the ZYNQ platform to avoid single points of failure caused by the ZYNQ platform's PS loading failure preventing system initialization and thus the reconstruction process from failing to start. Furthermore, to enhance the reliability of Reconstruction Module 1 itself, a triple modular redundancy (TMR) and dynamic flashing hardening scheme are implemented.

[0072] Reconfiguration module 1 includes a reconfiguration storage submodule 11 and a reconfiguration command submodule 12. The reconfiguration command submodule 12 receives and parses upgrade reconfiguration commands injected from the ground uplink and maintenance reconfiguration commands issued by the on-orbit monitoring system. The reconfiguration command submodule 12 connects to the ZYNQ platform 2 and sends the parsed upgrade reconfiguration commands or maintenance reconfiguration commands to the ZYNQ platform 2.

[0073] The reconstruction storage submodule 11 stores the upgrade reconstruction data packets or ground maintenance reconstruction data packets injected from the ground uplink. Specifically, the reconstruction storage submodule includes a PS storage unit and a PL storage unit. The PS storage unit uses a QSPI FLASH memory, and its capacity can support the storage of FSBL (First Stage Bootloader), u-boot program, and ELF format executable files. The PL storage unit uses an SPI NAND Flash memory to store PL configuration files (such as bitstream files).

[0074] ZYNQ platform 2 receives parsed upgrade / reconstruction or maintenance / reconstruction commands. If it is an upgrade / reconstruction command, it reads the upgrade / reconstruction data packet from the reconstruction storage submodule 11, executes the reconstruction process, and performs reconstruction verification. If it is a maintenance / reconstruction command, it reads one on-orbit maintenance / reconstruction data packet from the on-orbit storage module 3, executes the reconstruction process, and performs reconstruction verification. If the verification fails, it reads another on-orbit maintenance / reconstruction data packet. If the verification still fails after reading all on-orbit maintenance / reconstruction data packets and executing the reconstruction process, it reads the ground maintenance / reconstruction data packet from the reconstruction storage submodule 11 and executes the reconstruction process.

[0075] On-orbit storage module 3 includes an on-orbit PS storage section 31 and an on-orbit PL storage section 32. The on-orbit PS storage section 31 uses MRAM memory, and the PS boot files for different mirrors of the on-orbit maintenance and reconstruction data packets are stored in different partitions of the MRAM memory. The MRAM-based PS redundancy backup offers advantages such as non-volatility, high speed, and high reliability, significantly improving system fault tolerance and recovery efficiency. The on-orbit PL storage section 32 uses eMMC memory, and the bitstreams of different versions of PL data packets are stored in multiple different partitions of the eMMC memory. The eMMC memory uses multiple boot partitions, enabling independent storage and flexible switching of bitstream data partitions. During reconstruction, the latest version of the PL data packet bitstream is loaded first; if a verification error occurs, the next newest version of the PL data packet bitstream is loaded. The configuration and operational data of the ZYNQ platform 2, including the PS and PL sections, are periodically backed up and stored in the on-orbit storage module 3 to update the on-orbit maintenance and reconstruction data packets. The specific backup content includes: PS boot layer, including FSBL, U-Boot, and devicetree.dtb; PS system layer, including kernel image and kernel configuration parameters; PL configuration files, including .bin files; and runtime data, which are backed up incrementally.

[0076] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0077] In another embodiment, a computer device is provided, the internal structure of which can be as shown in the diagram. Figure 6 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores relevant data for an on-orbit reconfiguration method based on the ZYNQ platform. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements an on-orbit reconfiguration method based on the ZYNQ platform.

[0078] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0079] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0080] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0081] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for on-orbit reconfiguration based on a ZYNQ platform, characterized in that, The upgrade reconfiguration and the maintenance reconfiguration are included; For the upgrade reconfiguration, the upgrade reconfiguration instruction and the upgrade reconfiguration data packet are injected from the ground to the ZYNQ platform, the upgrade reconfiguration instruction is executed by the ZYNQ platform, the reconfiguration flow is executed through the upgrade reconfiguration data packet, and after completion, reconfiguration verification is performed, if the verification is incorrect, an error signal is sent to the ground, the upgrade reconfiguration data packet is re-injected from the ground, and the reconfiguration flow is re-executed; For the maintenance reconfiguration, at least two on-orbit maintenance reconfiguration data packets are stored in the on-orbit redundant memory, the maintenance reconfiguration flow is executed by the ZYNQ platform according to the maintenance reconfiguration instruction issued on-orbit through one on-orbit maintenance reconfiguration data packet, and after completion, reconfiguration verification is performed, if the verification is incorrect, another on-orbit maintenance reconfiguration data packet is switched to execute the maintenance reconfiguration flow, until the verification is correct or all on-orbit maintenance reconfiguration data packets are executed and the verification is still incorrect, if the verification is still incorrect, an error signal is sent to the ground, the ground maintenance reconfiguration data packet is injected from the ground, and the reconfiguration flow is executed through the ground maintenance reconfiguration data packet; During the execution of the upgrade reconfiguration instruction, the maintenance reconfiguration instruction is not executed; during the execution of the maintenance reconfiguration instruction, if the upgrade reconfiguration instruction is received, the maintenance reconfiguration instruction execution is stopped, and the upgrade reconfiguration instruction is executed instead; For the upgrade reconfiguration data packet or the ground maintenance reconfiguration data packet injected from the ground, when the ZYNQ platform executes the reconfiguration flow and the verification is correct, the on-orbit maintenance reconfiguration data packet is updated through the upgrade reconfiguration data packet or the ground maintenance reconfiguration data packet.

2. The on-orbit reconfiguration method based on the ZYNQ platform according to claim 1, wherein, The upgrade reconfiguration data packet or the ground maintenance reconfiguration data packet includes a PS data packet and a PL data packet, the PS data packet is used to reconfigure the PS part of the ZYNQ platform first, after completion, reconfiguration verification is performed, if the verification is incorrect, the PS data packet is re-injected from the ground, and the reconfiguration is re-executed, if the verification is correct, the PL data packet is used to reconfigure the PL part of the ZYNQ platform, after completion, reconfiguration verification is performed, if the verification is incorrect, the PL data packet is re-injected from the ground.

3. The on-orbit reconfiguration method based on the ZYNQ platform according to claim 2, characterized in that, The PS data packet and the PL data packet are stored in different storage modules.

4. The method of claim 1, wherein the ZYNQ platform is used to reconfigure the satellite in orbit. If the upgrade reconfiguration data packet or the ground maintenance reconfiguration data packet does not include the PL data packet, when the on-orbit maintenance reconfiguration data packet is updated through the upgrade reconfiguration data packet or the ground maintenance reconfiguration data packet, the configuration of the current PL part is used for updating.

5. The method of claim 1, wherein the ZYNQ platform-based on-orbit reconfiguration method is characterized by, Different on-orbit maintenance reconfiguration data packets are stored in different partitions of the storage module.

6. The on-orbit reconfiguration method based on the ZYNQ platform according to claim 5, characterized in that, For any on-orbit maintenance reconfiguration data packet, if the reconfiguration flow executed by the on-orbit maintenance reconfiguration data packet is incorrect after reconfiguration verification, the on-orbit maintenance reconfiguration data packet is marked, and after the reconfiguration flow is completed, the on-orbit maintenance reconfiguration data packet is updated based on the on-orbit maintenance reconfiguration data packet or the ground maintenance reconfiguration data packet which is correct.

7. A ZYNQ platform-based on-orbit reconfiguration system, characterized in that, It includes: a reconfiguration module, a ZYNQ platform, and an on-orbit storage module; the reconfiguration module includes a reconfiguration storage submodule and a reconfiguration instruction submodule; The reconstruction instruction sub-module is connected with the ZYNQ platform, receives an upgrade reconstruction instruction injected from the ground or a maintenance reconstruction instruction issued in orbit, and analyzes the received instruction, and sends the analyzed instruction to the ZYNQ platform; the reconstruction storage sub-module stores an upgrade reconstruction data packet injected from the ground or a ground maintenance reconstruction data packet; The ZYNQ platform receives the analyzed instruction, reads an upgrade reconstruction data packet from the reconstruction storage sub-module, executes a reconstruction process, and performs reconstruction verification if the instruction is an upgrade reconstruction instruction; If the instruction is a maintenance reconstruction instruction, the ZYNQ platform reads a stored in-orbit maintenance reconstruction data packet from the in-orbit storage module, executes a reconstruction process, and performs reconstruction verification; if the verification fails, another in-orbit maintenance reconstruction data packet is read; if the verification still fails after all in-orbit maintenance reconstruction data packets are read and processed, a ground maintenance reconstruction data packet is read from the reconstruction storage sub-module to execute a reconstruction process; during execution of an upgrade reconstruction instruction, no maintenance reconstruction instruction is executed; during execution of a maintenance reconstruction instruction, if an upgrade reconstruction instruction is received, the execution of the maintenance reconstruction instruction is stopped, and the upgrade reconstruction instruction is executed instead. The in-orbit storage module is partitioned, and a plurality of in-orbit maintenance reconstruction data packets are stored in different partitions of the in-orbit storage module.

8. The ZYNQ platform based on-orbit reconfiguration system according to claim 7, characterized in that, The reconstruction storage sub-module includes a PS storage unit and a PL storage unit, the PS storage unit uses a QSPI FLASH memory, and the PL storage unit uses a SPI NAND Flash memory.

9. The ZYNQ platform based on-orbit reconfiguration system according to claim 7, wherein, The in-orbit storage module includes an in-orbit PS storage unit and an in-orbit PL storage unit, the in-orbit PS storage unit uses an MRAM memory, and PS boot files of different in-orbit maintenance reconstruction data packets are stored in different partitions of the MRAM memory, the in-orbit PL storage unit uses an eMMC memory, and PL bitstream files of different in-orbit maintenance reconstruction data packets are stored in different partitions of the eMMC memory. 10.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-9. The processor executes the computer program to implement the steps of the in-orbit reconstruction method based on the ZYNQ platform according to any one of claims 1 to 6.

Images