Layered collaborative satellite-borne base station firmware upgrading method and device, equipment and medium

Abstract

The invention discloses a hierarchical collaborative satellite-borne base station firmware upgrading method, device and equipment and a medium, and the method comprises the steps: calling a pre-configured hierarchical collaborative architecture in response to a base station firmware upgrading instruction issued by a ground control system; sequentially reading and running a first-layer execution code corresponding to the basic loading layer, reading and running a second-layer execution code corresponding to the pre-upgrading decision-making layer, and reading and running an execution code corresponding to the upgrading control layer; and in response to a received upgrade completion confirmation instruction issued by the ground control system, writing an upgrade success mark and the latest version information of the firmware to be upgraded into a preset state storage area of the Flash storage module, and ending the upgrade process. According to the embodiment of the invention, modular management of satellite-borne base station firmware upgrading is realized through layered architecture and intelligent strategy selection, and the success rate of near-earth orbit satellite-borne base station firmware upgrading is remarkably improved finally in combination with ground remote confirmation and process recoverable design.

Description

Technical Field

[0001] This invention relates to the field of spaceborne communication technology, and in particular to a layered collaborative method, apparatus, device, and medium for upgrading the firmware of a spaceborne base station. Background Technology

[0002] With the development of satellite communication technology, satellite-based base stations, as core equipment for achieving seamless global coverage, are facing increasingly prominent demands for functional iteration and on-orbit maintenance. Currently, firmware upgrades for satellite-based base stations mainly draw on mature solutions for ground-based equipment, generally adopting an upgrade mechanism based on storage partition backup. This type of solution typically divides the memory into two or more regions, achieving version switching by completely transmitting the new firmware version and updating the boot flag.

[0003] When applied to spaceborne environments, traditional firmware upgrade solutions exhibit fundamental contradictions between their underlying architecture and space operation requirements: (1) Traditional solutions deeply couple upgrade functions with business systems, requiring complete system reconstruction for any adjustment to upgrade strategies, making them unsuitable for the dynamic adjustment needs of spaceborne base stations for upgrade strategies; (2) The lack of continuous tracking of upgrade progress results in the inability to resume transmission from interrupted points when the system encounters unexpected interruptions; (3) The inability to distinguish the root causes of various anomalies in the space environment leads to systemic deficiencies in traditional solutions, such as low upgrade efficiency, limited success rate, and insufficient resource utilization, in the space environment. Summary of the Invention

[0004] Based on this, the present invention provides a hierarchical collaborative method, apparatus, device and medium for upgrading firmware of spaceborne base stations. Through a hierarchical collaborative upgrade architecture and a dynamically configurable upgrade strategy, it solves the problems of low firmware upgrade efficiency, poor reliability and insufficient environmental adaptability of spaceborne base stations in the space environment.

[0005] In a first aspect, embodiments of the present invention provide a layered and collaborative method for upgrading the firmware of a spaceborne base station, comprising:

[0006] During one power-on working cycle of the satellite-borne base station, in response to the base station firmware upgrade command issued by the ground control system, the pre-configured layered collaborative architecture is invoked; wherein, the layered collaborative architecture includes a basic loading layer, a pre-upgrade decision layer and an upgrade control layer, each layer corresponds to the execution code that implements its functional logic, and the execution code of each layer is stored in a preset dedicated area of ​​the Flash storage module.

[0007] Read and run the first-layer execution code corresponding to the basic loading layer in the dedicated area of ​​the Flash storage module in the layered collaborative architecture. Divide the dedicated memory reserved for the upgrade process in the random access memory matched with the base station CPU into a data temporary storage area and a code execution area. At the same time, after enabling the peripheral interface and completing the initialization of the data transmission encryption and decryption rules, generate an initialization completion trigger signal.

[0008] In response to the initialization completion trigger signal, the second-layer execution code corresponding to the pre-upgrade decision layer is read and run. The current version number of the firmware to be upgraded is compared with the latest version number of the firmware to be upgraded carried in the base station firmware upgrade instruction. Based on the version number comparison result, the corresponding upgrade strategy and the splitting rules of the adaptation upgrade strategy are generated.

[0009] In response to the generation of the splitting rules, the executable code corresponding to the upgrade control layer in the exclusive area of ​​the Flash storage module is read and run. According to the upgrade strategy, the data to be written and the storage location information are obtained, and the data to be written is split into multiple data groups according to the splitting rules.

[0010] Each data group is temporarily stored in the data temporary storage area as the current data to be written. After the data transmission encryption and decryption rules are verified, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the consistency verification between the data to be written and the target data to be written in the target storage area is performed.

[0011] Through the peripheral interface, the verification results of each data group are fed back to the ground control system in real time. In response to the upgrade completion confirmation command issued by the ground control system, the upgrade success flag and the latest version information of the firmware to be upgraded are written into the preset status storage area of ​​the Flash storage module, and the upgrade process ends.

[0012] Secondly, embodiments of the present invention also provide a layered collaborative satellite base station firmware upgrade device, comprising:

[0013] The layered collaborative architecture invocation module is used to invoke the pre-configured layered collaborative architecture in response to the base station firmware upgrade command issued by the ground control system during one power-on working cycle of the satellite base station. The layered collaborative architecture includes a basic loading layer, a pre-upgrade decision layer, and an upgrade control layer. Each layer corresponds to the execution code that implements its functional logic, and the execution code of each layer is stored in a preset dedicated area of ​​the Flash storage module.

[0014] The basic loading layer execution module is used to read and run the first-layer execution code corresponding to the basic loading layer in the dedicated area of ​​the Flash storage module in the layered collaborative architecture. It divides the dedicated memory reserved for the upgrade process in the random access memory matched with the base station CPU into a data temporary storage area and a code execution area. After enabling the peripheral interface and completing the initialization of the data transmission encryption and decryption rules, it generates an initialization completion trigger signal.

[0015] The upgrade decision layer execution module is used to respond to the initialization completion trigger signal, read and run the second-layer execution code corresponding to the pre-upgrade decision layer, compare the current version number of the firmware to be upgraded with the latest version number of the firmware to be upgraded carried in the base station firmware upgrade instruction, and generate the corresponding upgrade strategy and the splitting rules of the adaptation upgrade strategy according to the version number comparison result.

[0016] The upgrade control layer execution module is used to respond to the generation of the splitting rules, read the execution code corresponding to the upgrade control layer in the exclusive area of ​​the Flash storage module and run it, obtain the data to be written and the storage location information according to the upgrade strategy, and split the data to be written into multiple data groups according to the splitting rules.

[0017] The consistency verification module is used to temporarily store each data group as the current data to be written in the data temporary storage area in turn. After the data transmission encryption and decryption rules are verified, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the data to be written and the target data to be written in the target storage area are verified for consistency.

[0018] The upgrade result feedback module is used to feed back the verification results of each data group to the ground control system in real time through the peripheral interface. In response to receiving the upgrade completion confirmation command issued by the ground control system, the module writes the upgrade success flag and the latest version information of the firmware to be upgraded into the preset status storage area of ​​the Flash storage module and ends the upgrade process.

[0019] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0020] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute a hierarchical collaborative satellite base station firmware upgrade method according to any embodiment of the present invention.

[0021] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute and implement a hierarchical collaborative satellite base station firmware upgrade method as described in any embodiment of the present invention.

[0022] This invention, through a layered architecture design comprising a basic loading layer, a pre-upgrade decision layer, and an upgrade control layer, achieves modularization and configurable strategies for the firmware upgrade process of spaceborne base stations. Based on version comparison and intelligent selection of differential upgrade strategies, it significantly improves upgrade efficiency within a limited communication window. Employing data verification and space-ground collaborative confirmation mechanisms ensures system reliability even under abnormal space environment conditions, preventing equipment from becoming unusable. Through state storage and process recoverability design, it effectively addresses transient interruptions, ultimately achieving a substantial improvement in the success rate of firmware upgrades for near-Earth orbit spaceborne base stations.

[0023] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart of a layered collaborative satellite base station firmware upgrade method according to Embodiment 1 of the present invention;

[0026] Figure 2 This is a flowchart of another layered collaborative satellite base station firmware upgrade method provided in Embodiment 2 of the present invention;

[0027] Figure 3 This is a schematic diagram of the structure of a layered collaborative satellite base station firmware upgrade device according to Embodiment 3 of the present invention;

[0028] Figure 4 This is a schematic diagram of the structure of an electronic device that implements a layered collaborative satellite base station firmware upgrade method according to an embodiment of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Example 1

[0032] Figure 1 This is a flowchart illustrating a hierarchical collaborative firmware upgrade method for a spaceborne base station according to Embodiment 1 of the present invention. This embodiment is applicable to firmware upgrade tasks for near-Earth orbit satellite base stations within a short communication window. The method can be executed by a hierarchical collaborative spaceborne base station firmware upgrade device, which can be implemented in hardware and / or software and can be configured in the embedded system of the spaceborne base station. Figure 1 As shown, the method includes:

[0033] S110. During one power-on working cycle of the satellite-borne base station, in response to the base station firmware upgrade command issued by the ground control system, the pre-configured layered collaborative architecture is invoked; wherein, the layered collaborative architecture includes a basic loading layer, a pre-upgrade decision layer and an upgrade control layer, each layer corresponding to the execution code that implements its functional logic, and the execution code of each layer is stored in a preset dedicated area of ​​the Flash storage module.

[0034] In this embodiment, the spaceborne base station is a base station device deployed on a low Earth orbit satellite to provide space communication services. Due to limitations imposed by the satellite's power supply system, it requires periodic power-on operation. The ground control system is a satellite communication management and control platform deployed on the ground, used to issue upgrade commands and firmware data to be upgraded to the spaceborne base station, and to receive upgrade status feedback. The layered collaborative architecture is a three-layer functional modular architecture designed for spaceborne base station firmware upgrades. Through layered collaboration of "initialization-decision-execution," it reduces the impact of single-level failures on the overall upgrade and adapts to the high reliability requirements of the spaceborne environment. The basic loading layer is the bottom layer of the layered collaborative architecture, responsible for basic preparations such as hardware initialization and memory allocation before the upgrade, providing runtime environment support for the subsequent upgrade process. The pre-upgrade decision layer is the middle layer of the layered collaborative architecture, responsible for version comparison, upgrade necessity judgment, and upgrade strategy formulation, serving as the decision-making link connecting basic preparation and actual upgrade. The upgrade control layer is the execution layer of the layered collaborative architecture, responsible for actual upgrade operations such as acquiring, splitting, writing, and verifying the data to be upgraded, and completing the firmware update according to the strategy formulated by the decision layer.

[0035] The core reason for limiting the upgrade process to a single power-on cycle is that satellite-based base stations rely on satellite solar power and are only powered on in areas with terrestrial communication coverage or in orbital segments with sufficient energy. If the upgrade process spans multiple power-on cycles, data loss and incomplete Flash writing may occur due to power outages. Therefore, the entire process must be completed within a single power-on period. The upgrade process is divided into three layers: "basic preparation - decision-making - execution." This avoids the spread of faults caused by complex code at a single level. The basic loading layer is only responsible for initialization, the pre-upgrade decision-making layer is only responsible for strategy formulation, and the upgrade control layer is only responsible for execution. The layers are connected through signal triggers to improve upgrade reliability. The code at each level is stored independently in the Flash storage module. This avoids overwriting between different levels of code during writing and allows for on-demand reading.

[0036] Optionally, before invoking the pre-configured hierarchical collaborative architecture in response to a base station firmware upgrade command issued by the ground control system, the following may also be included:

[0037] In response to the layered framework construction start command, the execution logic for base station firmware upgrade is divided according to the preset hierarchical principle, forming an architecture boundary that includes a basic loading layer, a pre-upgrade decision layer, and an upgrade control layer.

[0038] The base station hardware driver library and encryption algorithm development package are called. Based on the architecture boundary, the execution code of the basic loading layer, the pre-upgrade decision layer and the upgrade control layer are developed respectively. After verifying the validity of the execution code of each layer, the execution code corresponding to the execution logic of each layer is obtained.

[0039] Obtain the pre-configured Flash storage parameters, calculate the actual space occupied by the execution code of each layer, divide the non-overlapping exclusive area for the execution code of each layer in the base station Flash storage according to the Flash address mapping rules, and write the execution code of each layer into the corresponding exclusive area to obtain the initial layered collaborative framework;

[0040] The system acquires simulated main program call signals and ground upgrade instructions, tests the connection effectiveness of the execution code of each layer in the initial hierarchical collaboration framework, and obtains the hierarchical collaboration framework for base station firmware upgrade after passing the connection effectiveness test.

[0041] The pre-defined hierarchical principle refers to the core criteria for dividing the upgrade execution logic, specifically "functional independence + low coupling + high cohesion." Each level is responsible for only a single core function, and the levels are connected through clear signal interfaces to avoid the spread of faults caused by functional overlap, adapting to the high reliability requirements of the spaceborne environment. The architecture boundary defines the functional scope of the basic loading layer, pre-upgrade decision layer, and upgrade control layer, clearly defining the input / output parameters, calling relationships, and responsibility boundaries of each level. The base station hardware driver library refers to the collection of drivers for spaceborne base station hardware devices, including low-level operation interfaces such as hardware initialization and read / write control, providing hardware access support for the execution code at each level. The Flash address mapping rule specifies the allocation method for Flash storage areas, which must meet the principles of "no overlap of code areas at each level + continuous addresses + easy reading," such as allocating the starting address segment of Flash to the basic loading layer, and subsequently allocating the remaining address segments to other levels.

[0042] The basis for dedicated area division is as follows: First, the total address space range is determined through Flash storage parameters. Then, the actual number of bytes for each level of code is calculated (e.g., the basic loading layer code occupies 10KB, the pre-upgrade decision layer occupies 15KB, and the upgrade control layer occupies 20KB). Areas are allocated according to the principle of "contiguous address + no overlap." For example, Flash addresses 0x000000-0x0027FF are allocated to the basic loading layer, 0x002800-0x005FFF to the pre-upgrade decision layer, and 0x006000-0x00AFFF to the upgrade control layer. After the code of each level is solidified into the dedicated area of ​​the Flash storage module, an architectural entity that can be called by the main program of the satellite base station is formed. In subsequent upgrade processes, the system only needs to read the code of the corresponding area to start each level, without the need for redevelopment or loading.

[0043] The simulated main program call signal is the activation signal for the hierarchical collaborative framework after the simulated spaceborne base station main program detects the upgrade command, verifying whether the framework can be triggered normally. The simulated ground upgrade command is an upgrade command with the same format as the actual one issued by the debugging system, verifying the framework's ability to parse the command. By simulating real-world scenarios, it is ensured that the framework can seamlessly interact with the spaceborne base station main program and the ground control system after actual deployment.

[0044] S120 reads the first-layer execution code corresponding to the base loading layer in the exclusive area of the Flash storage module in the hierarchical collaboration architecture and runs it. The dedicated memory reserved for the upgrade process in the random access memory supporting the on-board base station CPU is divided into a data temporary storage area and a code execution area. After enabling the peripheral interface and completing the initialization of the data transmission encryption and decryption rules, an initialization completion trigger signal is generated.

[0045] The preset exclusive area of the Flash storage module is three independent storage areas divided according to the address mapping rule in the on-board base station Flash storage module, which store the execution codes of the base loading layer, the pre-upgrade decision layer, and the upgrade control layer respectively, to avoid address conflicts or mutual interference between codes of different levels. The first-layer execution code is the executable code corresponding to the base loading layer, and its core function is to complete the initialization operation before the upgrade. The random access memory (RAM) is a temporary storage medium supporting the on-board base station CPU, which is used to temporarily store data and run the execution code during the upgrade process. The data temporary storage area is one of the sub-areas divided in the dedicated memory, which is used to temporarily store the firmware data to be written into the Flash storage module as a turnover buffer. The code execution area is one of the sub-areas divided in the dedicated memory, which is used to load and run the execution codes of the pre-upgrade decision layer and the upgrade control layer to ensure that the subsequent layer codes can be directly called and executed by the CPU. The peripheral interface is the hardware interface in the on-board base station for communicating with the ground control system, which has been adapted to the space-ground communication protocol and supports the transmission of upgrade instructions, firmware data, and verification results. The data transmission encryption and decryption rules are the encryption, decryption, and verification algorithms pre-configured in the on-board base station, which are used to ensure the security and integrity of the upgrade data transmission between space and ground and prevent data tampering or leakage.

[0046] During the upgrade process, it is necessary to simultaneously realize the temporary storage of the data to be upgraded and the running of the codes of the subsequent two layers. Splitting the data temporary storage area and the code execution area can avoid the data writing and code execution from抢占内存地址 (grabbing memory addresses), resulting in data confusion or code execution crashes. The data temporary storage area is only used for data turnover, and the code execution area is only used for code loading. The functional isolation improves the stability. The peripheral interface is the only link for space-ground communication. During initialization, the communication parameter configuration and link self-check need to be completed to ensure that subsequent operations such as upgrade instruction feedback, data transmission, and verification result reporting can be carried out normally, and to avoid communication interruptions caused by the unreadiness of the interface. The initialization completion trigger signal is used as the synchronization signal between layers to ensure that after the base loading layer completes all preparation work, the pre-upgrade decision layer is started, and to avoid the failure of subsequent steps caused by the incomplete previous preparations (such as the second-layer code cannot be loaded if the code execution area is not allocated).

[0047] Furthermore, the dedicated memory reserved for the upgrade process in the random access memory (RAM) associated with the base station CPU is divided into a data temporary storage area and a code execution area. Simultaneously, after enabling the peripheral interface and completing the initialization of data transmission encryption / decryption rules, an initialization completion trigger signal is generated, which may include:

[0048] Based on the predefined upgrade process memory requirements, the required space size of the data temporary storage area and the code execution area is calculated. Based on the required space size, a first contiguous address space is allocated for the data temporary storage area and a second contiguous address space is allocated for the code execution area in the random access memory, and the first contiguous address space and the second contiguous address space do not overlap.

[0049] Traverse the list of preset peripheral interfaces related to communication with the satellite base station, initialize the communication parameters of each peripheral interface, and enable the peripheral interface after completing the interface link self-test.

[0050] Load the pre-configured encryption algorithm, initialize the key parameters and verification threshold required for data transmission, and complete the algorithm runtime environment self-check to confirm that the encryption and decryption rules can be called normally;

[0051] Once the dedicated memory allocation is completed, the peripheral interface is successfully enabled, and the encryption / decryption rules are initialized, an initialization completion trigger signal with a status identifier is generated to trigger the execution code call of the pre-upgrade decision layer.

[0052] The predefined upgrade process memory requirements refer to the pre-defined memory usage standards based on the onboard base station upgrade scenario. These include the maximum total number of data groups the data buffer area needs to support, and the peak memory usage for the pre-upgrade decision layer and upgrade control layer's execution code. This serves as the basis for calculating the size of the two memory areas. The first contiguous address space refers to the contiguous address segment allocated to the data buffer area in dedicated RAM memory; its address range is fixed and unique. The second contiguous address space is the contiguous address segment allocated to the code execution area in dedicated RAM memory, and it does not overlap with the first contiguous address space. The encryption algorithm is a pre-configured security algorithm in the onboard base station, specifically a symmetric encryption algorithm or a hash verification algorithm. The status identifier is the binary status information carried in the initialization completion trigger signal (e.g., "0x00" represents incomplete, "0x01" represents complete), used to clearly identify the initialization result of the basic loading layer, allowing the pre-upgrade decision layer to accurately identify the start-up timing.

[0053] Predefined memory requirements must be determined in conjunction with the onboard base station hardware resources and upgrade scenarios. The data buffer space must cover "maximum data group size × number of simultaneous buffer groups" to ensure no overflow during data turnover. The code execution area space must cover "pre-upgrade decision layer code size + upgrade control layer code size + runtime stack space" to avoid crashes due to insufficient memory during code execution. The onboard environment is affected by space radiation, orbital position changes, etc., and peripheral interface links are prone to momentary failures. During self-test, link connectivity can be verified through handshake testing, and data transmission accuracy can be verified through test data packet transmission. The interface is only enabled after the self-test passes to avoid subsequent upgrade command reception failures or data transmission errors due to interface anomalies. Trigger signal generation requires three conditions to be met: "memory partitioning completed + interface enabled successfully + encryption / decryption initialization passed." None of these conditions can be missing. If memory partitioning is not completed, subsequent code will have no execution space; if the interface is not enabled, upgrade strategy-related data cannot be received; if encryption / decryption rules are unavailable, data transmission security cannot be guaranteed. Multi-condition judgments ensure that basic preparation work is not omitted, providing a stable operating environment for subsequent upgrade processes.

[0054] S130. In response to the initialization completion trigger signal, read and run the second-layer execution code corresponding to the pre-upgrade decision layer, compare the current version number of the firmware to be upgraded with the latest version number of the firmware to be upgraded carried in the base station firmware upgrade instruction, and generate the corresponding upgrade strategy and the splitting rules of the adaptation upgrade strategy according to the version number comparison result.

[0055] The initialization completion trigger signal is a binary identifier signal generated after the basic loading layer completes all initialization operations. It is used to notify the system to start the execution code of the pre-upgrade decision layer. The second-layer execution code is the executable code corresponding to the pre-upgrade decision layer, stored in a pre-defined dedicated area of ​​Flash. Its core functions are version comparison, upgrade strategy generation, and splitting rule formulation. The upgrade strategy is an upgrade method based on version difference type, firmware attributes, and base station operating status, specifying how to obtain the data to be written. The splitting rules are data splitting standards adapted to the upgrade strategy and Flash hardware characteristics (such as the smallest read / write unit), specifying the size of data groups, identification rules, and splitting order to ensure that data writing is compatible with the Flash storage module.

[0056] The strategy type is jointly determined by "version difference type + firmware attributes + base station operating status". For example, cross-version differences may adopt a full upgrade strategy, patch version differences may adopt a differential upgrade strategy, and when the base station has insufficient remaining storage capacity, a pre-storage upgrade strategy may be adopted. The splitting rules need to match the data flow characteristics of the upgrade strategy. For example, the data flow of a full upgrade strategy is continuous, and the splitting rules can set the data group size according to the smallest read / write unit of the Flash storage module; the data flow of a differential upgrade strategy corresponds to discrete addresses, and the splitting rules need to group by address range to ensure that the data can be accurately written to the target storage area after splitting, while reducing the impact of a single transmission failure.

[0057] S140. In response to the generation of the splitting rules, read and run the execution code corresponding to the upgrade control layer in the exclusive area of ​​the Flash storage module, obtain the data to be written and the storage location information according to the upgrade strategy, and split the data to be written into multiple data groups according to the splitting rules.

[0058] The third-layer execution code is stored in a dedicated area pre-defined by the Flash storage module. It corresponds to the upgrade control layer and its core functions include data acquisition, splitting, writing, and verification. The data to be written is firmware data acquired according to the upgrade strategy, such as a complete program image, binary differential data, and pre-stored fragmented data after splicing. This is the core data ultimately written to the target Flash storage area. The storage location information specifies the address parameters of the target Flash storage area, obtained from the upgrade instructions, guiding the precise writing of data groups. A data group is an independent data block formed by splitting the data to be written according to the splitting rules. Each data group contains a unique identifier and sequence number, and its capacity is adapted to the smallest read / write unit of the Flash storage module, facilitating group-by-group transmission, verification, and writing.

[0059] The data acquisition method is defined by the upgrade strategy. The complete upgrade strategy receives complete program image data from the ground control system, the differential upgrade strategy receives pre-calculated binary differential data from the ground, and the pre-storage upgrade strategy reads and splices fragmented data stored in historical power cycles, ensuring that the data acquisition method matches the strategy and adapts to the bandwidth limitations of space-to-ground communication. In the spaceborne environment, the Flash storage module has a minimum read / write unit limit (e.g., 4KB / page), and the data group size must be adapted to this unit. At the same time, small data groups facilitate group-by-group verification and retransmission. If the transmission or writing of a data group fails, only that group needs to be retransmitted, without retransmitting all the data, thus improving upgrade efficiency and reliability.

[0060] S150. Each data group is temporarily stored in the data temporary storage area as the current data to be written. After the data transmission encryption and decryption rules are verified, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the data to be written and the target data to be written in the target storage area are checked for consistency.

[0061] The target storage area refers to a dedicated area within the Flash storage module reserved for the final firmware storage. It is the location where the upgraded firmware's runtime data is stored, with a fixed address range and isolated from other areas. Consistency verification involves comparing the written data in the target area with the original data in the data buffer in Random Access Memory (RAM) after the data is written to the Flash storage module, performing a byte-level comparison to verify the accuracy of the data write. Data to be written is first temporarily stored in the data buffer area, rather than directly written to the Flash storage module. This is because RAM has a faster read / write speed, improving data verification efficiency; and secondly, it prevents data corruption in the Flash storage module due to data transmission errors or verification failures when directly writing to the Flash storage module. The RAM buffer area acts as a buffer verification area, ensuring that the data written to the Flash storage module is valid.

[0062] The first layer of verification checks the integrity and security of data transmission during the satellite-to-ground transmission process, eliminating erroneous data during transmission. The second layer of verification checks the accuracy of data after it is written, eliminating hardware write errors. This dual protection ensures the validity of the upgrade data. Data is written sequentially according to the data group number to avoid address conflicts caused by writing multiple data groups in parallel. At the same time, each data group is verified immediately after writing, which can detect and record errors in real time, facilitating subsequent retransmission or upgrade interruption, and preventing the entire upgrade process from failing due to an error in one data group.

[0063] S160. Through the peripheral interface, the verification results of each data group are fed back to the ground control system in real time. In response to the upgrade completion confirmation command issued by the ground control system, the upgrade success flag and the latest version information of the firmware to be upgraded are written into the preset status storage area of ​​the Flash storage module, and the upgrade process ends.

[0064] The preset status storage area is a dedicated area in the Flash storage module for storing upgrade status information. It records upgrade success or failure flags, version information, and reasons for failure, facilitating subsequent queries or anomaly recovery. The ground control system needs to monitor the transmission and writing status of each data group in real time. If a data group fails verification, a retransmission command can be issued promptly to avoid missing retransmission opportunities due to feedback delays. Simultaneously, real-time feedback allows the ground to intuitively monitor the upgrade progress. Due to signal delays in satellite-to-ground communication, after the satellite base station completes verification of all data groups, it must wait for the ground to receive all feedback and issue confirmation commands before recording the upgrade success status. This prevents inconsistencies caused by the ground not receiving all feedback while the base station has already recorded a success status. The upgrade success flag and latest version number stored in the preset status storage area are read by the base station upon the next power-on. If a success flag is detected, there is no need to repeat the upgrade; if no success flag is detected or a failure flag is detected, a re-upgrade process can be triggered, ensuring that the upgrade results are traceable and recoverable.

[0065] Optionally, after feeding back the verification results of each data group to the ground control system in real time through the peripheral interface, the system may further include:

[0066] If no upgrade completion confirmation instruction is received from the ground control system within the preset time, the upgrade process is deemed to have failed.

[0067] The current version number in the preset state storage area remains unchanged. Based on the verification results of each data group that have been fed back, the last data group with a successful verification result is determined.

[0068] The last data group with a successful verification result is recorded as upgrade failure information in the preset state storage area. After releasing the memory resources allocated for this upgrade process in the data temporary storage area and code execution area, the upgrade process is exited.

[0069] In this embodiment, the preset time refers to the waiting time set by combining the round-trip delay of space-to-ground communication with the single power-on cycle of the satellite base station. It must cover the entire process of ground receiving verification results, generating confirmation commands, and transmitting them back, to avoid misjudging upgrade failure due to communication delays. The upgrade completion confirmation command is the final confirmation signal sent by the ground control system to the satellite base station after receiving feedback that all data groups have passed verification. It contains a binary identifier indicating that the upgrade process can be terminated and is the sole trigger for the base station to record the upgrade success status. Upgrade failure information is key data for recording upgrade interruption status. Its core includes the sequence number, storage address, and verification timestamp of the last successful data group, used to quickly locate the upgrade breakpoint upon the next power-on, avoiding repeated execution of completed write operations.

[0070] In practical applications, onboard upgrades must ensure the firmware is complete and functional. Failure to receive a confirmation command indicates that the ground-based final verification result has not been confirmed, and the firmware may contain undiscovered anomalies. A failed upgrade can promptly terminate the process, preventing subsequent errors. The version number in the preset state storage area is the basis for determining whether to "load valid firmware" upon the base station's next power-on. If the upgrade is incomplete (no confirmation command received), the firmware may be in an incomplete state. Maintaining the original version number ensures that the old, normal firmware is loaded upon the next power-on, preventing base station malfunction due to incomplete firmware loading. Onboard RAM capacity is typically small; if the memory occupied by the upgrade process is not released, the base station's main program may fail to run due to insufficient memory. A dual operation of "address marking + data zeroing" ensures that memory resources can be safely reused, with no residual data interfering with subsequent processes.

[0071] This invention, through a layered architecture design comprising a basic loading layer, a pre-upgrade decision layer, and an upgrade control layer, achieves modularization and configurable strategies for the firmware upgrade process of spaceborne base stations. Based on version comparison and intelligent selection of differential upgrade strategies, it significantly improves upgrade efficiency within a limited communication window. Employing data verification and space-ground collaborative confirmation mechanisms ensures system reliability even under abnormal space environment conditions, preventing equipment from becoming unusable. Through state storage and process recoverability design, it effectively addresses transient interruptions, ultimately achieving a substantial improvement in the success rate of firmware upgrades for near-Earth orbit spaceborne base stations.

[0072] Example 2

[0073] Figure 2 This is a flowchart of another layered collaborative satellite base station firmware upgrade method provided in Embodiment 2 of the present invention. This embodiment is a refinement based on Embodiment 1, specifically as follows: Figure 2 As shown, the method includes:

[0074] S210. During one power-on working cycle of the satellite-borne base station, in response to the base station firmware upgrade command issued by the ground control system, the pre-configured layered collaborative architecture is invoked; wherein, the layered collaborative architecture includes a basic loading layer, a pre-upgrade decision layer, and an upgrade control layer, each layer corresponding to the execution code that implements its functional logic, and the execution code of each layer is stored in a preset dedicated area of ​​the Flash storage module.

[0075] S220. Read and run the first-layer execution code corresponding to the basic loading layer in the dedicated area of ​​the Flash storage module in the layered collaborative architecture. Divide the dedicated memory reserved for the upgrade process in the random access memory matched with the base station CPU into a data temporary storage area and a code execution area. At the same time, after enabling the peripheral interface and completing the initialization of the data transmission encryption and decryption rules, generate an initialization completion trigger signal.

[0076] S230. In response to the initialization completion trigger signal, read and run the second-level execution code corresponding to the pre-upgrade decision layer, and read the version number of the currently running firmware from the firmware storage area of ​​the Flash storage module as the current version number of the firmware to be upgraded.

[0077] The firmware storage area is an independent area in the Flash storage module of the satellite base station specifically used to store the currently running firmware and firmware version information. Its address range does not overlap with the dedicated areas of the code at each level of the hierarchical collaborative architecture, ensuring that firmware data is stored in isolation from the architecture code.

[0078] S240. Parse the data packet structure of the base station firmware upgrade instruction and extract the latest version number and firmware attribute information of the firmware to be upgraded.

[0079] The data packet structure of the base station firmware upgrade command follows the format specification of upgrade commands issued by the ground control system, typically including three parts: a command header, a data segment, and a checksum tail, adapted to the data packet parsing logic of satellite-to-ground communication. Firmware attribute information, the core characteristic parameters of the firmware to be upgraded, may include firmware size, module composition, data integrity checksum values, compatible base station hardware models, etc., and is a key basis for formulating the upgrade strategy.

[0080] S250. According to the preset version number comparison rules, perform consistency verification between the current version number and the latest version number to determine the version difference type.

[0081] The preset version number comparison rule is based on the version number comparison standard preset by the satellite base station. A "major-minor revision number hierarchical comparison method" can be used, with priority given to major version number > minor version number > revision number, ensuring the accuracy of version difference judgment. Version difference type refers to the difference category based on the version number comparison results, mainly including no version difference (the current version is completely identical to the latest version), patch version difference (only the revision number is different, such as V1.2.3 and V1.2.4), cross-minor version difference (different minor version numbers, such as V1.2.3 and V1.3.0), and cross-major version difference (different major version numbers, such as V1.2.3 and V2.0.0).

[0082] S260. If it is determined that there is no version difference, then generate a termination upgrade strategy and an empty splitting rule.

[0083] The upgrade termination policy refers to the upgrade control policy generated when it is determined that there is no version difference. Its core content is "stop subsequent upgrade operations and directly report that the upgrade does not need to be executed," avoiding the use of CPU, memory, and other resources by the satellite base station when no upgrade is needed, thus adapting to the energy-saving requirements of satellite equipment. The empty splitting rule is a data splitting rule that complements the upgrade termination policy. It has no actual data splitting logic and only serves as an interface compatibility identifier between the policy and subsequent processes, ensuring uninterrupted logical connections between layers.

[0084] S270. If a version difference is determined, a corresponding upgrade strategy is generated based on the firmware attribute information. At the same time, the hardware parameters of the base station Flash storage module are obtained, the minimum read / write unit size of the Flash storage module is determined, and a splitting rule adapted to the current upgrade strategy is generated based on the minimum read / write unit size and the determined upgrade strategy. The upgrade strategy includes at least a complete upgrade strategy, a differential upgrade strategy, and a pre-stored upgrade strategy.

[0085] The hardware parameters of the base station Flash storage module are key parameters describing the characteristics of Flash storage. Besides the minimum read / write unit size, these parameters may also include storage block erase / write lifetime, address mapping table, bad block management rules, etc., to ensure that the partitioning rules are compatible with the Flash hardware characteristics. The minimum read / write unit size refers to the smallest data unit that the spaceborne base station Flash storage module can stably read and write in a single operation. It is a core constraint for setting the data group size, preventing write errors caused by data groups spanning multiple units.

[0086] The upgrade strategy is generated by combining firmware attribute information and difference type for comprehensive judgment. For example: ① Cross-master version difference + moderate firmware size: select the full upgrade strategy; ② Patch version difference + only local module modification: select the differential upgrade strategy; Firmware size exceeds the single power-on communication bandwidth: select the pre-storage upgrade strategy. The full upgrade strategy is suitable for scenarios with large firmware architecture adjustments and high module compatibility requirements. Its advantage is high firmware integrity after the upgrade, but the risk is large data transmission volume. The differential upgrade strategy is suitable for scenarios with local code modifications. Its advantages are small data volume and fast transmission, but the risk is reliance on the accuracy of the base version. The pre-storage upgrade strategy is suitable for scenarios with large firmware data volume and insufficient single power-on communication bandwidth. Its advantage is that data can be pre-stored in multiple power-on cycles, but the risk is the need to manage the sequence and integrity of fragmented data.

[0087] S280. In response to the generation of the splitting rules, read and run the execution code corresponding to the upgrade control layer in the exclusive area of ​​the Flash storage module, obtain the data to be written and the storage location information according to the upgrade strategy, and split the data to be written into multiple data groups according to the splitting rules.

[0088] Optionally, according to the upgrade strategy, the data to be written and the storage location information are obtained, and the data to be written is split into multiple data groups according to the splitting rules, which may include:

[0089] If the upgrade strategy is a complete upgrade strategy, then the complete program image data of the firmware to be upgraded is received from the ground control system through the peripheral interface and directly used as the data to be written. According to the minimum read / write unit size, the data to be written is divided into multiple data pages of fixed size in sequence. Multiple data groups are formed by generating continuous storage positioning information for each data page.

[0090] If the upgrade strategy is a differential upgrade strategy, the binary differential data pre-calculated by the ground control system is received and parsed through the peripheral interface as the data to be written. According to the address range grouping rules defined in the splitting rules, the binary differential data is divided into multiple data blocks, and storage positioning information containing its starting address and data length is generated for each data block to form multiple data groups.

[0091] If the upgrade strategy is a pre-storage upgrade strategy, then all sub-data packets that have been received and stored in multiple historical power-on working cycles are read from the pre-storage area of ​​the base station Flash storage module. According to the sequence identifier of the sub-data packets, the data payloads of all sub-data packets are sequentially spliced ​​together to form the complete program image data of the firmware to be upgraded and used as the data to be written.

[0092] Based on the minimum read / write unit size, the assembled complete program image data is divided into multiple data pages of fixed size. By generating continuous storage location information for each data page, multiple data groups are formed.

[0093] The complete program image data is a complete binary file of the firmware to be upgraded. It can contain the code and configuration data of all functional modules such as baseband processing, RF control, and protocol stack. Its size is adapted to the capacity of the onboard Flash firmware storage area and is the core data to be written in the complete upgrade strategy. Data pages are fixed-size data blocks divided according to the smallest read / write unit size of the Flash. They represent the specific form of data groups in the complete upgrade and pre-storage upgrade strategies, ensuring that the data writing action matches the Flash hardware read / write characteristics and avoiding cross-unit write errors. Continuous storage positioning information consists of address parameters under the complete upgrade and pre-storage upgrade strategies, composed of the target storage area start address + data page sequence number offset (e.g., start address 0x020000, page 1 offset 0x000000), ensuring that data pages are written to the Flash continuously in logical order. Binary differential data refers to the difference data generated by the ground control system through a differential algorithm comparing the old and new firmware. It only contains the modified parts, and its data volume is much smaller than the complete image, making it suitable for onboard scenarios with limited space-to-ground communication bandwidth. The address range grouping rule refers to the exclusive splitting rule for differential upgrades. It groups data according to the original firmware address range corresponding to the binary differential data, ensuring that each data block corresponds to a specific continuous address range in Flash, thus avoiding writing differential data to incorrect locations. The pre-storage area is a temporary storage area for fragmented data in the onboard Flash, independent of the firmware or state storage area. It is used to store sub-data packets received in historical power-on cycles under the pre-storage upgrade strategy, and its address range does not overlap with other areas. Sub-data packets are firmware fragments distributed in batches from the ground during the pre-storage upgrade, containing a "sequence identifier + data payload." The sequence identifier is used for sorting, and the data payload is part of the firmware's binary content, adapted to the short communication window of a single power-on cycle on the satellite.

[0094] To address the bandwidth limitations of satellite-to-ground communication, a "fragmented transmission + real-time verification" mode is adopted. The ground station splits the complete image into small data segments for transmission. Each received segment is verified using data transmission encryption / decryption rules to prevent signal interruption due to large single transmission volumes. After reception, the segments are stitched together to form a complete image, ensuring data integrity. The minimum read / write unit of Flash memory dictates that the data page size must be an integer multiple; if the image size is not an integer multiple, invalid bytes are padded at the end. The firmware is segmented according to the "code segment → data segment" firmware logical order to ensure that the firmware can be loaded by the CPU with consecutive addresses after writing.

[0095] The ground system pre-generates a differential file containing "difference data + original address offset". After receiving the file, the base station parses and extracts the binary differential data and corresponding address information. The differential data corresponds to discrete address segments in the original firmware. Grouping by address intervals ensures that each data block corresponds to a continuous address segment in Flash. The stored positioning information contains "starting address + data length", ensuring that the data block is directly overwritten to the target address without rewriting the entire firmware, thus improving upgrade efficiency.

[0096] The short communication window during a single power-on operation on a satellite makes it impossible to transmit large firmware data in a single cycle. The ground-based system sends sub-data packets in batches across multiple power-on cycles. Upon receiving these packets, the base station immediately stores them in a pre-storage area and records their sequence identifiers, thus overcoming the communication window limitation by breaking down the large packets into smaller ones. The sub-data packets are sorted in ascending order by their sequence identifiers, and only the data payload is extracted and concatenated after removing control information. After concatenation, the complete mirror hash value is verified using data transmission encryption and decryption rules to ensure the concatenated result matches the complete ground firmware, avoiding sorting errors or data loss.

[0097] After splicing, a complete program image is obtained. Therefore, the same splitting method as the complete upgrade strategy is adopted: data pages are divided according to the smallest read / write unit, and continuous positioning information is generated. Unified logic can reduce the complexity of the upgrade control layer code and adapt to the limited computing power of the onboard CPU. Pre-storage solves the problem of "large firmware cannot be transferred in one go", and splitting solves the problem of "Flash hardware read / write unit limitation". The combination of the two makes onboard upgrade of large firmware feasible and balances communication limitations and hardware characteristics.

[0098] S290. Each data group is temporarily stored in the data temporary storage area as the current data to be written. After the data transmission encryption and decryption rules are verified, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the data to be written and the target data to be written in the target storage area are checked for consistency.

[0099] Furthermore, each data group is sequentially stored as the current data to be written in the data temporary storage area. After passing the data transmission encryption and decryption rule verification, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the consistency verification between the data to be written and the target data to be written in the target storage area can be performed, which may include:

[0100] Each data group formed according to the splitting rules will be stored sequentially in the data temporary storage area and marked as the data to be written.

[0101] The data transmission encryption and decryption rules are used to perform integrity verification on the current data to be written in the target data temporary storage area. If the integrity verification fails, the current data group is discarded and the ground control system is requested to retransmit the current data group through the peripheral interface.

[0102] If the integrity check passes, the data to be written is written to the corresponding target storage area of ​​the Flash storage module according to the storage location information corresponding to the current data group. After the writing operation is completed, the data to be written is read back from the target storage area as the target data to be written.

[0103] The target data to be written is compared byte by byte with the current data to be written temporarily stored in the data temporary storage area to perform a consistency check.

[0104] If the consistency check passes, an acknowledgment signal is generated confirming the successful write to the current data group, and the currently pending data in the data buffer is cleared.

[0105] If the consistency check fails, the operation of writing the current data to be written to the target storage area will be re-executed. After the operation fails again after repeating the operation up to the preset maximum number of times, the current data group will be marked as having failed to write.

[0106] The target data buffer zone refers to an independent sub-region within the data buffer zone allocated for the data to be written. It is isolated from the buffer spaces of other data groups to prevent interference when multiple data groups are buffered simultaneously. The address range is determined by the address allocation rules of the data buffer zone. When integrity verification fails, the base station sends a retransmission command to the ground control system via an external interface. This command includes the sequence number and identifier of the current data group, ensuring accurate location and retransmission of the corresponding data group by the ground, adapting to scenarios where satellite-to-ground communication is susceptible to interference. After data is written to the Flash storage module, the complete data at the corresponding address segment is immediately read from the target storage area as the target write data. This data is then compared with the original buffer data to verify the accuracy of the write operation. The preset maximum number of retries is the maximum number of retries set for data group write failures. This is determined by the hardware characteristics of the satellite base station and the reliability requirements of upgrades, avoiding infinite retries in the upgrade process due to hardware failures and wasting satellite resources.

[0107] Discarding failed data sets frees up temporary storage space, preventing invalid data from consuming resources. Retransmission requests carry the data set sequence number, eliminating the need for the ground to retransmit all data, only the corresponding set, reducing satellite-to-ground communication load. This is crucial for spaceborne scenarios with short communication windows during single power-on cycles, enabling fault repair within a limited time. Generating acknowledgment signals for subsequent ground feedback and clearing temporary data frees up memory space, preparing for the next set of data to be temporarily stored.

[0108] S2100. Through the peripheral interface, the verification results of each data group are fed back to the ground control system in real time. In response to the upgrade completion confirmation command issued by the ground control system, the upgrade success flag and the latest version information of the firmware to be upgraded are written into the preset status storage area of ​​the Flash storage module, and the upgrade process ends.

[0109] This invention describes a complete upgrade process, from intelligent version decision-making to secure data writing, through a detailed breakdown of the overall solution. Specifically, it automatically selects the optimal upgrade strategy through intelligent version comparison, employing differentiated data processing mechanisms such as paging, address grouping, and multi-cycle data integration for full upgrades, differential upgrades, and pre-storage upgrades, respectively. By establishing dual guarantees of integrity verification and readback comparison, combined with retransmission and breakpoint resumption functions, it effectively adapts to the communication constraints of the spaceborne environment while ensuring data reliability, achieving a balance between firmware upgrade efficiency and reliability.

[0110] Example 3

[0111] Figure 3 This is a schematic diagram of a layered collaborative spaceborne base station firmware upgrade device provided in Embodiment 3 of the present invention. Figure 3 As shown, the device includes:

[0112] The layered collaborative architecture calling module 310 is used to call the pre-configured layered collaborative architecture in response to the base station firmware upgrade command issued by the ground control system during one power-on working cycle of the satellite base station; wherein, the layered collaborative architecture includes a basic loading layer, a pre-upgrade decision layer and an upgrade control layer, each layer corresponding to the execution code that implements its functional logic, and the execution code of each layer is stored in a preset dedicated area of ​​the Flash storage module.

[0113] The basic loading layer execution module 320 is used to read and run the first-layer execution code corresponding to the basic loading layer in the dedicated area of ​​the Flash storage module in the layered collaborative architecture. It divides the dedicated memory reserved for the upgrade process in the random access memory matched with the base station CPU into a data temporary storage area and a code execution area. After enabling the peripheral interface and completing the initialization of the data transmission encryption and decryption rules, it generates an initialization completion trigger signal.

[0114] The upgrade decision layer execution module 330 is used to respond to the initialization completion trigger signal, read and run the second-layer execution code corresponding to the pre-upgrade decision layer, compare the current version number of the firmware to be upgraded with the latest version number of the firmware to be upgraded carried in the base station firmware upgrade instruction, and generate the corresponding upgrade strategy and the splitting rules of the adaptation upgrade strategy according to the version number comparison result.

[0115] The upgrade control layer execution module 340 is used to respond to the generation of the splitting rules, read the execution code corresponding to the upgrade control layer in the exclusive area of ​​the Flash storage module and run it, obtain the data to be written and the storage location information according to the upgrade strategy, and split the data to be written into multiple data groups according to the splitting rules.

[0116] The consistency verification module 350 is used to temporarily store each data group as the current data to be written in the data temporary storage area in turn. After the data transmission encryption and decryption rule is verified, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the data to be written is verified to be consistent with the target data to be written in the target storage area.

[0117] The upgrade result feedback module 360 ​​is used to feed back the verification results of each data group to the ground control system in real time through the peripheral interface. In response to receiving the upgrade completion confirmation command issued by the ground control system, it writes the upgrade success flag and the latest version information of the firmware to be upgraded into the preset status storage area of ​​the Flash storage module and ends the upgrade process.

[0118] This invention, through a layered architecture design comprising a basic loading layer, a pre-upgrade decision layer, and an upgrade control layer, achieves modularization and configurable strategies for the firmware upgrade process of spaceborne base stations. Based on version comparison and intelligent selection of differential upgrade strategies, it significantly improves upgrade efficiency within a limited communication window. Employing data verification and space-ground collaborative confirmation mechanisms ensures system reliability even under abnormal space environment conditions, preventing equipment from becoming unusable. Through state storage and process recoverability design, it effectively addresses transient interruptions, ultimately achieving a substantial improvement in the success rate of firmware upgrades for near-Earth orbit spaceborne base stations.

[0119] Optionally, based on the above embodiments, it may also include: a layered collaborative architecture building unit, used to divide the execution logic of base station firmware upgrade according to a preset hierarchical principle in response to the layered framework construction start command before calling the pre-configured layered collaborative architecture in response to the base station firmware upgrade command issued by the ground control system, forming an architecture boundary including a basic loading layer, a pre-upgrade decision layer and an upgrade control layer.

[0120] The base station hardware driver library and encryption algorithm development package are called. Based on the architecture boundary, the execution code of the basic loading layer, the pre-upgrade decision layer and the upgrade control layer are developed respectively. After verifying the validity of the execution code of each layer, the execution code corresponding to the execution logic of each layer is obtained.

[0121] Obtain the pre-configured Flash storage parameters, calculate the actual space occupied by the execution code of each layer, divide the non-overlapping exclusive area for the execution code of each layer in the base station Flash storage according to the Flash address mapping rules, and write the execution code of each layer into the corresponding exclusive area to obtain the initial layered collaborative framework;

[0122] The system acquires simulated main program call signals and ground upgrade instructions, tests the connection effectiveness of the execution code of each layer in the initial hierarchical collaboration framework, and obtains the hierarchical collaboration framework for base station firmware upgrade after passing the connection effectiveness test.

[0123] Optionally, based on the above embodiments, the basic loading layer execution module 320 may include:

[0124] The memory space partitioning unit is used to calculate the required space size of the data temporary storage area and the code execution area according to the predefined memory requirements of the upgrade process. Based on the required space size, it allocates a first contiguous address space for the data temporary storage area and a second contiguous address space for the code execution area in the random access memory, and the first contiguous address space and the second contiguous address space do not overlap.

[0125] The peripheral interface enabling unit is used to traverse the preset peripheral interface list related to communication with the satellite base station, initialize the communication parameters of each peripheral interface, and enable the peripheral interface after completing the interface link self-test.

[0126] The encryption / decryption rule initialization unit is used to load the pre-configured encryption algorithm, initialize the key parameters and verification threshold required for data transmission, and complete the algorithm running environment self-check to confirm that the encryption / decryption rules can be called normally.

[0127] The first-level execution completion unit is used to generate an initialization completion trigger signal with a status identifier after the dedicated memory allocation is completed, the peripheral interface is successfully enabled, and the encryption and decryption rules are initialized. This signal is used to trigger the execution code call of the pre-upgrade decision layer.

[0128] Optionally, based on the above embodiments, upgrading the decision-making layer execution module 330 may include:

[0129] The original version number reading unit is used to read the version number of the currently running firmware from the firmware storage area of ​​the Flash storage module, and use it as the current version number of the firmware to be upgraded.

[0130] The new version number extraction unit is used to parse the data packet structure of the base station firmware upgrade instruction and extract the latest version number and firmware attribute information of the firmware to be upgraded carried therein.

[0131] The version difference type determination unit is used to perform consistency verification between the current version number and the latest version number according to a preset version number comparison rule, and determine the version difference type.

[0132] The no-version-difference execution unit is used to generate a termination upgrade strategy and an empty splitting rule if it is determined that there is no version difference.

[0133] A version difference execution unit is provided, which, if a version difference is determined to exist, generates a corresponding upgrade strategy based on the firmware attribute information, obtains the hardware parameters of the base station Flash storage module, determines the minimum read / write unit size of the Flash storage module, and generates a splitting rule adapted to the current upgrade strategy based on the minimum read / write unit size and the determined upgrade strategy; wherein, the upgrade strategy includes at least a complete upgrade strategy, a differential upgrade strategy, and a pre-stored upgrade strategy.

[0134] Optionally, based on the above embodiments, the upgraded control layer execution module 340 may include:

[0135] The complete upgrade strategy execution unit is used to receive the complete program image data of the firmware to be upgraded from the ground control system through the peripheral interface if the upgrade strategy is a complete upgrade strategy, and directly use it as the data to be written. According to the minimum read / write unit size, the data to be written is divided into multiple data pages of fixed size in sequence, and multiple data groups are formed by generating continuous storage positioning information for each data page.

[0136] The differential upgrade strategy execution unit is used to receive and parse the binary differential data pre-calculated by the ground control system as the data to be written through the peripheral interface if the upgrade strategy is a differential upgrade strategy. According to the address range grouping rules defined in the splitting rules, the binary differential data is divided into multiple data blocks, and storage positioning information containing its starting address and data length is generated for each data block to form multiple data groups.

[0137] The historical sub-data packet splicing unit is used to read all sub-data packets that have been received and stored in multiple historical power-on working cycles from the pre-storage area of ​​the base station Flash storage module if the upgrade strategy is a pre-storage upgrade strategy. According to the sequence identifier of the sub-data packets, the data payloads of all sub-data packets are spliced ​​in sequence to form complete program image data of the firmware to be upgraded and used as data to be written.

[0138] The complete program image data segmentation unit is used to segment the spliced ​​complete program image data into multiple data pages of fixed size according to the minimum read / write unit size, and to form multiple data groups by generating continuous storage location information for each data page.

[0139] Optionally, based on the above embodiments, the consistency verification module 350 may include:

[0140] The data temporary storage unit is used to sequentially store each data group formed according to the splitting rules into the data temporary storage area and mark them as the data to be written.

[0141] The integrity verification unit is used to perform integrity verification on the current data to be written in the target data temporary storage area according to the data transmission encryption and decryption rules. If the integrity verification fails, the current data group is discarded and the ground control system is requested to retransmit the current data group through the peripheral interface.

[0142] The storage writing unit is used to write the current data to be written to the corresponding target storage area of ​​the Flash storage module according to the storage location information corresponding to the current data group if the integrity verification passes, and to read back the written current data to be written from the target storage area after the writing operation is completed, as the target data to be written.

[0143] The byte comparison unit is used to compare the target data to be written with the current data to be written temporarily stored in the data temporary storage area byte by byte to perform consistency verification.

[0144] The write success confirmation unit is used to generate a confirmation signal for the current data group to be written successfully if the consistency check passes, and to clear the current data to be written in the data buffer area.

[0145] The write failure confirmation unit is used to re-execute the operation of writing the current data to be written to the target storage area if the consistency check fails, and to mark the current data group as written failure after the re-execution reaches a preset maximum number of times.

[0146] Optionally, based on the above embodiments, it may also include: an upgrade failure confirmation unit, which is used to determine that the upgrade process has failed if the upgrade completion confirmation instruction issued by the ground control system is not received within a preset time after the verification results of each data group are fed back to the ground control system in real time through the peripheral interface.

[0147] The current version number in the preset state storage area remains unchanged. Based on the verification results of each data group that have been fed back, the last data group with a successful verification result is determined.

[0148] The last data group with a successful verification result is recorded as upgrade failure information in the preset state storage area. After releasing the memory resources allocated for this upgrade process in the data temporary storage area and code execution area, the upgrade process is exited.

[0149] The hierarchical collaborative satellite base station firmware upgrade device provided in this embodiment of the invention can execute the hierarchical collaborative satellite base station firmware upgrade method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0150] Example 4

[0151] Figure 4A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0152] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0153] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0154] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a hierarchical collaborative satellite base station firmware upgrade method.

[0155] That is, during one power-on working cycle of the satellite base station, in response to the base station firmware upgrade command issued by the ground control system, the pre-configured layered collaborative architecture is invoked; wherein, the layered collaborative architecture includes a basic loading layer, a pre-upgrade decision layer and an upgrade control layer, each layer corresponds to the execution code that implements its functional logic, and the execution code of each layer is stored in a preset dedicated area of ​​the Flash storage module.

[0156] Read and run the first-layer execution code corresponding to the basic loading layer in the dedicated area of ​​the Flash storage module in the layered collaborative architecture. Divide the dedicated memory reserved for the upgrade process in the random access memory matched with the base station CPU into a data temporary storage area and a code execution area. At the same time, after enabling the peripheral interface and completing the initialization of the data transmission encryption and decryption rules, generate an initialization completion trigger signal.

[0157] In response to the initialization completion trigger signal, the second-layer execution code corresponding to the pre-upgrade decision layer is read and run. The current version number of the firmware to be upgraded is compared with the latest version number of the firmware to be upgraded carried in the base station firmware upgrade instruction. Based on the version number comparison result, the corresponding upgrade strategy and the splitting rules of the adaptation upgrade strategy are generated.

[0158] In response to the generation of the splitting rules, the executable code corresponding to the upgrade control layer in the exclusive area of ​​the Flash storage module is read and run. According to the upgrade strategy, the data to be written and the storage location information are obtained, and the data to be written is split into multiple data groups according to the splitting rules.

[0159] Each data group is temporarily stored in the data temporary storage area as the current data to be written. After the data transmission encryption and decryption rules are verified, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the consistency verification between the data to be written and the target data to be written in the target storage area is performed.

[0160] Through the peripheral interface, the verification results of each data group are fed back to the ground control system in real time. In response to the upgrade completion confirmation command issued by the ground control system, the upgrade success flag and the latest version information of the firmware to be upgraded are written into the preset status storage area of ​​the Flash storage module, and the upgrade process ends.

[0161] In some embodiments, a hierarchical collaborative satellite base station firmware upgrade method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the hierarchical collaborative satellite base station firmware upgrade method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a hierarchical collaborative satellite base station firmware upgrade method by any other suitable means (e.g., by means of firmware).

[0162] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0163] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0164] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0165] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0166] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0167] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0168] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and no limitation is imposed herein.

[0169] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A hierarchical collaborative method for upgrading satellite-borne base station firmware, characterized in that, The satellite-borne base station operates periodically by powering on a low-Earth orbit satellite, including: During one power-on working cycle of the satellite-borne base station, in response to the base station firmware upgrade command issued by the ground control system, the pre-configured layered collaborative architecture is invoked; wherein, the layered collaborative architecture includes a basic loading layer, a pre-upgrade decision layer and an upgrade control layer, each layer corresponds to the execution code that implements its functional logic, and the execution code of each layer is stored in a preset dedicated area of ​​the Flash storage module. Read and run the first-layer execution code corresponding to the basic loading layer in the dedicated area of ​​the Flash storage module in the layered collaborative architecture. Divide the dedicated memory reserved for the upgrade process in the random access memory matched with the base station CPU into a data temporary storage area and a code execution area. At the same time, after enabling the peripheral interface and completing the initialization of the data transmission encryption and decryption rules, generate an initialization completion trigger signal. In response to the initialization completion trigger signal, the second-layer execution code corresponding to the pre-upgrade decision layer is read and run. The current version number of the firmware to be upgraded is compared with the latest version number of the firmware to be upgraded carried in the base station firmware upgrade instruction. Based on the version number comparison result, the corresponding upgrade strategy and the splitting rules of the adaptation upgrade strategy are generated. In response to the generation of the splitting rules, the executable code corresponding to the upgrade control layer in the exclusive area of ​​the Flash storage module is read and run. According to the upgrade strategy, the data to be written and the storage location information are obtained, and the data to be written is split into multiple data groups according to the splitting rules. Each data group is temporarily stored in the data temporary storage area as the current data to be written. After the data transmission encryption and decryption rules are verified, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the consistency verification between the data to be written and the target data to be written in the target storage area is performed. Through the peripheral interface, the verification results of each data group are fed back to the ground control system in real time. In response to the upgrade completion confirmation command issued by the ground control system, the upgrade success flag and the latest version information of the firmware to be upgraded are written into the preset status storage area of ​​the Flash storage module, and the upgrade process ends.

2. The method according to claim 1, characterized in that, Before invoking the pre-configured hierarchical collaborative architecture in response to the base station firmware upgrade command issued by the ground control system, the following steps are also included: In response to the layered framework construction start command, the execution logic for base station firmware upgrade is divided according to the preset hierarchical principle, forming an architecture boundary that includes a basic loading layer, a pre-upgrade decision layer, and an upgrade control layer. The base station hardware driver library and encryption algorithm development package are called. Based on the architecture boundary, the execution code of the basic loading layer, the pre-upgrade decision layer and the upgrade control layer are developed respectively. After verifying the validity of the execution code of each layer, the execution code corresponding to the execution logic of each layer is obtained. Obtain the pre-configured Flash storage parameters, calculate the actual space occupied by the execution code of each layer, divide the non-overlapping exclusive area for the execution code of each layer in the base station Flash storage according to the Flash address mapping rules, and write the execution code of each layer into the corresponding exclusive area to obtain the initial layered collaborative framework; The system acquires simulated main program call signals and ground upgrade instructions, tests the connection effectiveness of the execution code of each layer in the initial hierarchical collaboration framework, and obtains the hierarchical collaboration framework for base station firmware upgrade after passing the connection effectiveness test.

3. The method according to claim 1, characterized in that, The dedicated memory reserved for the upgrade process in the random access memory (RAM) associated with the base station CPU is divided into a data temporary storage area and a code execution area. After enabling the peripheral interface and completing the initialization of data transmission encryption / decryption rules, an initialization completion trigger signal is generated, including: Based on the predefined upgrade process memory requirements, the required space size of the data temporary storage area and the code execution area is calculated. Based on the required space size, a first contiguous address space is allocated for the data temporary storage area and a second contiguous address space is allocated for the code execution area in the random access memory, and the first contiguous address space and the second contiguous address space do not overlap. Traverse the list of preset peripheral interfaces related to communication with the satellite base station, initialize the communication parameters of each peripheral interface, and enable the peripheral interface after completing the interface link self-test. Load the pre-configured encryption algorithm, initialize the key parameters and verification threshold required for data transmission, and complete the algorithm runtime environment self-check to confirm that the encryption and decryption rules can be called normally; Once the dedicated memory allocation is completed, the peripheral interface is successfully enabled, and the encryption / decryption rules are initialized, an initialization completion trigger signal with a status identifier is generated to trigger the execution code call of the pre-upgrade decision layer.

4. The method according to claim 1, characterized in that, The current version number of the firmware to be upgraded is compared with the latest version number of the firmware to be upgraded carried in the base station firmware upgrade instruction. Based on the version number comparison result, a corresponding upgrade strategy and a splitting rule for the adaptation upgrade strategy are generated, including: Read the version number of the currently running firmware from the firmware storage area of ​​the Flash storage module, and use it as the current version number of the firmware to be upgraded; The data packet structure of the base station firmware upgrade instruction is parsed to extract the latest version number and firmware attribute information of the firmware to be upgraded. According to the preset version number comparison rules, the consistency between the current version number and the latest version number is checked to determine the type of version difference; If it is determined that there is no version difference, then a termination upgrade strategy and an empty splitting rule are generated; If a version difference is determined, a corresponding upgrade strategy is generated based on the firmware attribute information. At the same time, the hardware parameters of the base station Flash storage module are obtained, the minimum read / write unit size of the Flash storage module is determined, and a splitting rule adapted to the current upgrade strategy is generated based on the minimum read / write unit size and the determined upgrade strategy. The upgrade strategy includes at least a complete upgrade strategy, a differential upgrade strategy, and a pre-stored upgrade strategy.

5. The method according to claim 4, characterized in that, According to the upgrade strategy, the data to be written and the location information to be stored are obtained. The data to be written is then split into multiple data groups according to the splitting rules, including: If the upgrade strategy is a complete upgrade strategy, then the complete program image data of the firmware to be upgraded is received from the ground control system through the peripheral interface and directly used as the data to be written. According to the minimum read / write unit size, the data to be written is divided into multiple data pages of fixed size in sequence. Multiple data groups are formed by generating continuous storage positioning information for each data page. If the upgrade strategy is a differential upgrade strategy, the binary differential data pre-calculated by the ground control system is received and parsed through the peripheral interface as the data to be written. According to the address range grouping rules defined in the splitting rules, the binary differential data is divided into multiple data blocks, and storage positioning information containing its starting address and data length is generated for each data block to form multiple data groups. If the upgrade strategy is a pre-storage upgrade strategy, then all sub-data packets that have been received and stored in multiple historical power-on working cycles are read from the pre-storage area of ​​the base station Flash storage module. According to the sequence identifier of the sub-data packets, the data payloads of all sub-data packets are sequentially spliced ​​together to form the complete program image data of the firmware to be upgraded and used as the data to be written. Based on the minimum read / write unit size, the assembled complete program image data is divided into multiple data pages of fixed size. By generating continuous storage location information for each data page, multiple data groups are formed.

6. The method according to claim 5, characterized in that, Each data group is sequentially stored as the current data to be written in the data temporary storage area. After passing the data transmission encryption and decryption rule verification, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the data to be written and the target data to be written in the target storage area are checked for consistency, including: Each data group formed according to the splitting rules will be stored sequentially in the data temporary storage area and marked as the data to be written. The data transmission encryption and decryption rules are used to perform integrity verification on the current data to be written in the target data temporary storage area. If the integrity verification fails, the current data group is discarded and the ground control system is requested to retransmit the current data group through the peripheral interface. If the integrity check passes, the data to be written is written to the corresponding target storage area of ​​the Flash storage module according to the storage location information corresponding to the current data group. After the writing operation is completed, the data to be written is read back from the target storage area as the target data to be written. The target data to be written is compared byte by byte with the current data to be written temporarily stored in the data temporary storage area to perform a consistency check. If the consistency check passes, an acknowledgment signal is generated confirming the successful write to the current data group, and the currently pending data in the data buffer is cleared. If the consistency check fails, the operation of writing the current data to be written to the target storage area will be re-executed. After the operation fails again after repeating the operation up to the preset maximum number of times, the current data group will be marked as having failed to write.

7. The method according to claim 1, characterized in that, After feeding back the verification results of each data group to the ground control system in real time through the peripheral interface, the system also includes: If no upgrade completion confirmation instruction is received from the ground control system within the preset time, the upgrade process is deemed to have failed. The current version number in the preset state storage area remains unchanged. Based on the verification results of each data group that have been fed back, the last data group with a successful verification result is determined. The last data group with a successful verification result is recorded as upgrade failure information in the preset state storage area. After releasing the memory resources allocated for this upgrade process in the data temporary storage area and code execution area, the upgrade process is exited.

8. A layered collaborative spaceborne base station firmware upgrade device, characterized in that, The device includes: The layered collaborative architecture invocation module is used to invoke the pre-configured layered collaborative architecture in response to the base station firmware upgrade command issued by the ground control system during one power-on working cycle of the satellite base station. The layered collaborative architecture includes a basic loading layer, a pre-upgrade decision layer, and an upgrade control layer. Each layer corresponds to the execution code that implements its functional logic, and the execution code of each layer is stored in a preset dedicated area of ​​the Flash storage module. The basic loading layer execution module is used to read and run the first-layer execution code corresponding to the basic loading layer in the dedicated area of ​​the Flash storage module in the layered collaborative architecture. It divides the dedicated memory reserved for the upgrade process in the random access memory matched with the base station CPU into a data temporary storage area and a code execution area. After enabling the peripheral interface and completing the initialization of the data transmission encryption and decryption rules, it generates an initialization completion trigger signal. The upgrade decision layer execution module is used to respond to the initialization completion trigger signal, read and run the second-layer execution code corresponding to the pre-upgrade decision layer, compare the current version number of the firmware to be upgraded with the latest version number of the firmware to be upgraded carried in the base station firmware upgrade instruction, and generate the corresponding upgrade strategy and the splitting rules of the adaptation upgrade strategy according to the version number comparison result. The upgrade control layer execution module is used to respond to the generation of the splitting rules, read the execution code corresponding to the upgrade control layer in the exclusive area of ​​the Flash storage module and run it, obtain the data to be written and the storage location information according to the upgrade strategy, and split the data to be written into multiple data groups according to the splitting rules. The consistency verification module is used to temporarily store each data group as the current data to be written in the data temporary storage area in turn. After the data transmission encryption and decryption rules are verified, the current data to be written is written to the target storage area of ​​the Flash storage module according to the storage location information. After the writing is completed, the data to be written and the target data to be written in the target storage area are verified for consistency. The upgrade result feedback module is used to feed back the verification results of each data group to the ground control system in real time through the peripheral interface. In response to receiving the upgrade completion confirmation command issued by the ground control system, the module writes the upgrade success flag and the latest version information of the firmware to be upgraded into the preset status storage area of ​​the Flash storage module and ends the upgrade process.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a hierarchical collaborative satellite base station firmware upgrade method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute and implement the hierarchical collaborative satellite base station firmware upgrade method according to any one of claims 1-7.

Images