Spaceborne network operating system assurance method based on dual flash

Abstract

The application provides a dual-Flash-based satellite-borne network operating system guarantee method, adopts a main Flash memory and a backup Flash memory to store a boot program Uboot and a micro system ONIE, and constructs an image array to store a network operating system NOS; the guarantee method comprises dual-Flash partition planning, Uboot main-backup cooperation and single particle effect repair, Uboot environment variable main-backup checking and repair, ONIE system main-backup backup and integrity checking repair, and SSD hard disk reliability guarantee and single particle effect repair. The purpose of low cost and high reliable operation of the satellite-borne network operating system is achieved. The method can be used in combination with a traditional three-mode redundancy scheme, and can also be used as a backup reliability guarantee scheme after failure of a three-mode redundancy chip.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of satellite communication, and particularly relates to a satellite-borne network operating system guarantee method based on double Flash. BACKGROUND

[0002] In the running process of the satellite-borne network device, the stable and reliable network operating system is the core guarantee to ensure the smooth completion of key tasks such as satellite communication and networking. The space environment where the satellite-borne device is located is extremely harsh, and there are a large number of high-energy particles. These particles are prone to cause single event effects, including single event upsets (SEU) and single event latchup (SEL). Single event upsets can cause errors in the data in the storage unit, such as bit flips in the firmware program, environmental variables and operating system related files in the Flash memory, and further cause program running abnormities, system startup failures and other problems. Single event latchup can cause large currents in the device, causing device damage and affecting the normal work of the Flash or SSD hard disk, ultimately causing the satellite-borne network operating system to fail to run normally.

[0003] Currently, the storage media commonly used in satellite-borne devices include Nor Flash memory and SSD hard disk. Among them, Nor Flash is usually in the order of MB in size and has a single function. If a traditional partition table method is used for management, it will cause waste of space and is difficult to meet the demand of efficient use of storage resources of satellite-borne devices. At the same time, for the booting and starting of the satellite-borne network operating system, the Bootloader (such as Uboot) is usually relied on to complete hardware initialization and kernel loading. However, under the traditional single Flash architecture, once the Uboot firmware in the Flash is damaged, it will directly cause the system to fail to start, and there is a lack of effective repair mechanism. In addition, the environmental variables of Uboot, as important configuration parameters for system startup, will also affect the normal startup and configuration of the system if they are wrong or lost due to single event upsets and other factors.

[0004] To realize the installation and deployment of the satellite-borne network operating system, the underlying firmware system needs to provide a standardized installation interface, file verification and refreshing capability, and hard disk partition and file system automatic repair capability. However, the traditional Uboot startup mechanism lacks the above complete environment and is difficult to meet the installation needs of the satellite-borne network operating system. Although some schemes introduce an intermediate layer system (such as the ONIE microsystem) to build an installation basic environment, the backup mechanism of the ONIE microsystem in the existing scheme is not perfect, and the problem of file damage caused by single event effects in the space environment is not fully considered, which cannot ensure the reliable startup of the microsystem, and further affects the installation and running of the subsequent satellite-borne network operating system.

[0005] On the other hand, in the storage and running of the satellite-borne network operating system NOS, the traditional scheme usually uses a single SSD hard disk for storage, and lacks an effective primary and backup backup mechanism. Once the SSD hard disk is damaged due to single event latch-up and other factors, the operating system file will be lost or cannot be read, and it is difficult to guarantee the reliable operation of the operating system. Even if some schemes use multiple SSD hard disks, they are not optimized for single event effects in the satellite-borne environment, lack effective verification and repair strategies, and cannot timely discover and repair file damage problems caused by single event upset, and the reliability is insufficient. SUMMARY

[0006] In view of the problems in the prior art, the present application provides a satellite-borne network operating system guarantee method based on double Flash, which at least partially solves the problem of insufficient reliability in the prior art.

[0007] The present application provides a satellite-borne network operating system guarantee method based on double Flash, which uses a main Flash memory and a backup Flash memory to store the boot program Uboot and the micro system ONIE, and uses at least two SSD hard disks to build an image array to store the network operating system NOS.

[0008] The guarantee method includes double Flash partition planning, Uboot primary and backup cooperation and single event effect repair, Uboot environment variable primary and backup verification and repair, ONIE system primary and backup backup and integrity verification and repair, and SSD hard disk reliability guarantee and single event effect repair.

[0009] Optionally, the double Flash partition planning includes:

[0010] The main Flash memory and the backup Flash memory use the same physical address allocation scheme for partitioning, and the partitioning is defined by setting a macro. The partitioning includes a first address range for storing the Uboot firmware program, a second address range for storing the Uboot environment variable, a third address range used as a reserved area, and a fourth address range for storing the ONIE micro system. The data stored in the third address range includes verification data.

[0011] Optionally, the Uboot primary and backup cooperation and single event effect repair includes:

[0012] When the device is powered on, the primary and backup registers of the programmable logic device CPLD control the Uboot to be started from the main Flash memory preferentially, and the starting process is monitored through a watchdog mechanism.

[0013] If the main Flash memory fails to start, the programmable logic device CPLD is switched to start from the backup Flash memory by the watchdog timeout trigger, and a main-backup Flash memory switching and repair process is performed;

[0014] During the Uboot running process, the Uboot firmware programs in the main-backup Flash memories are periodically checked, if the checking fails due to single event upset, a main-backup Flash memory switching and repair process is triggered, if the main Flash memory is damaged due to single event latch-up, the backup Flash memory is directly switched to start.

[0015] Optionally, the main-backup registers of the programmable logic device CPLD control the Uboot to start from the main Flash memory preferentially, and the starting process is monitored through the watchdog mechanism, including:

[0016] If the Uboot firmware program in the main Flash memory can be normally started, after the starting, whether the version numbers of the Uboot firmware programs in the main-backup Flash memories are consistent is checked;

[0017] If the version numbers are consistent, the watchdog is closed, and the ONIE microsystem is loaded;

[0018] If the version numbers are inconsistent, the Uboot firmware program in the main Flash memory is overwritten into the backup Flash memory, a main-backup synchronization operation is completed, and after the synchronization is completed, the watchdog is closed.

[0019] Optionally, if the main Flash memory fails to start, the programmable logic device CPLD is switched to start from the backup Flash memory by the watchdog timeout trigger, and a main-backup Flash memory switching and repair process is performed, including:

[0020] If the Uboot firmware program in the main Flash memory fails to start, after waiting for a set time, the watchdog register is closed due to the timeout, the programmable logic device CPLD triggers a timeout scheme, selects the backup Flash memory and restarts the device, and attempts to start the Uboot firmware program from the backup Flash memory; if the Uboot firmware program in the backup Flash memory starts successfully, the Uboot firmware program in the backup Flash memory is copied into the main Flash memory, a main-backup switching operation is completed, after the copying is completed, whether the contents of the Uboot firmware programs in the main-backup Flash memories are consistent is compared;

[0021] If the contents are consistent, the programmable logic device CPLD switches to select the main Flash memory, and after the device is restarted, the main Flash memory is normally started;

[0022] If inconsistent, the device will start the Uboot firmware program from the backup Flash memory, maintain operation, and issue a fault alarm signal to the satellite integrated electronic component telemetry component, and start satellite network node emergency switching.

[0023] Optionally, the Uboot environment variable master-slave checking and repairing comprises:

[0024] The Uboot environment variable is checked in master-slave mode, when the master Flash memory environment variable checking fails, the environment variable in the backup Flash memory is used for repairing and synchronization, and if both fail, the default environment variable written in the Uboot program is enabled.

[0025] Optionally, the Uboot environment variable is checked in master-slave mode, which comprises master-slave environment variable consistency checking, when the environment variable in the master Flash memory is directly applied, the environment variables in the master Flash memory and the backup Flash memory are respectively read into two different addresses in the memory, and the data in the two addresses is directly compared to determine whether the master-slave environment variables are consistent.

[0026] If inconsistent, the environment variable in the master Flash memory is backed up to the backup Flash memory.

[0027] Optionally, the ONIE system master-slave backup and integrity checking and repairing comprises:

[0028] Before starting the ONIE system, the integrity of the ONIE system file in the master Flash memory is checked, if the checking fails, the ONIE system file in the backup Flash memory is used to start and repair the master Flash memory, and if the ONIE system files in the master and backup Flash memories are both damaged, the starting fails and an alarm is issued.

[0029] Optionally, the reliability guarantee and single particle effect repair of the SSD hard disk comprises:

[0030] When booting the NOS operating system, first, the integrity of the kernel startup file in the first SSD hard disk is checked, if the checking fails, the second SSD hard disk is switched to start, and the damaged file is repaired by using the mirror array, if the kernel startup files in the two SSD hard disks are both damaged, the starting fails and an alarm is issued.

[0031] Optionally, the reliability guarantee and single particle effect repair of the SSD hard disk comprises RAID1 configuration and metadata setting, the metadata is fixedly stored in the tail space of the SSD hard disk, and the first SSD hard disk and the second SSD hard disk are combined into a RAID1 disk array through the RAID1 algorithm.

[0032] The application provides a spaceborne network operating system guarantee method based on double Flash, which solves the problems of the existing spaceborne network operating system (NOS) in terms of startup reliability, environment variable stability, system installation basic environment and hard disk storage reliability by constructing an image array through a double Flash architecture design and an SSD hard disk, combining a Uboot firmware, a Uboot environment variable, a master-slave cooperation and a check and repair mechanism of an ONIE system, and adding repair measures for single event upset and single event latchup in a space environment, so as to achieve the purposes of low cost and high reliable operation of the spaceborne network operating system. BRIEF DESCRIPTION OF DRAWINGS

[0033] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which like reference characters refer to like parts throughout the figures, and in which:

[0034] Figure 1 A principle block diagram of the spaceborne network operating system guarantee method based on double Flash provided by the embodiment of the present disclosure is shown in the figure;

[0035] Figure 2 A schematic diagram of double Flash partition provided by the embodiment of the present disclosure is shown in the figure;

[0036] Figure 3 A flowchart of Uboot master-slave cooperation provided by the embodiment of the present disclosure is shown in the figure;

[0037] Figure 4 A flowchart of single event effect repair provided by the embodiment of the present disclosure is shown in the figure;

[0038] Figure 5 A flowchart of Uboot environment variable master-slave check and repair provided by the embodiment of the present disclosure is shown in the figure;

[0039] Figure 6 A schematic diagram of RAID1 configuration and metadata setting provided by the embodiment of the present disclosure is shown in the figure;

[0040] Figure 7 A flowchart of operating system startup check and repair provided by the embodiment of the present disclosure is shown in the figure. DETAILED DESCRIPTION

[0041] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0042] It should be apparent that the following description illustrates by way of example only a number of possible embodiments of the present disclosure. Those skilled in the art will readily understand other advantages and benefits of the present disclosure from the description that follows, without departing from the spirit of the disclosure. It should be apparent that the described embodiments are merely a few of the embodiments of the present disclosure, and are not all-inclusive of all embodiments of the present disclosure. The present disclosure can also be implemented or applied in other different specific embodiments, and the details in the description can be modified or changed based on different views and applications, without departing from the spirit of the present disclosure. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict. Based on the embodiments in the present disclosure, all other embodiments obtained by those of ordinary skill in the art without creative labor are within the scope of protection of the present disclosure.

[0043] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein can be implemented in a wide variety of forms and that any particular structure and / or function described herein is merely illustrative. Based on the teachings herein one skilled in the art will appreciate that one or more aspects described herein can be implemented independently of any other aspects and that non-dependent aspects can be implemented in conjunction with each other in any way. For example, a device can be implemented and / or a method practiced using any number of the aspects described herein. In addition, an apparatus can be implemented and / or a method practiced using other structure and / or functionality in addition to or other than one or more of the aspects described herein.

[0044] It should also be noted that the drawings provided in the following embodiments are only to illustrate the basic concept of the present disclosure in a schematic manner, and only show the components related to the present disclosure, not drawn according to the number, shape and size of the components in actual implementation, the shape, number and proportion of each component in actual implementation can be a random change, and the layout pattern of its components can be more complex.

[0045] In addition, in the following description, specific details are provided in order to facilitate a thorough understanding of the examples. However, one skilled in the art will understand that the aspects described can be practiced without these specific details.

[0046] The method of the present embodiment can be used in combination with the conventional triple modular redundancy scheme, and can also be used as a backup reliability guarantee scheme after the failure of a triple modular redundancy chip.

[0047] The dual-Flash-based satellite network operating system guarantee method of the embodiment. It is suitable for satellite network devices with high reliability requirements, complex space radiation environment, and strict cost control. Through the dual-Flash architecture and the corresponding master-slave cooperation and verification repair mechanism, the stable operation of the satellite network device operating system (Network Operating System, NOS) is guaranteed, and the file damage caused by single event upset and single event latch-up in the space environment has repair capability. This scheme can be used with the traditional triple modular redundancy scheme, and can also be used as a backup reliability guarantee scheme after the failure of the triple modular redundancy chip. Hereinafter, the Flash memory is referred to as Flash.

[0048] For ease of understanding, as Figure 1 shown, the embodiment discloses a dual-Flash-based satellite network operating system guarantee method, which stores UBOOT and microsystem ONIE based on two Flash memories of master Flash and backup Flash, and makes RAID1 for two SSD hard disks used for storing satellite network operating system NOS. The specific working process and reliability guarantee include the following steps:

[0049] Step one: dual-Flash partition planning:

[0050] Due to the limited size (usually in the MB level) and single function of NorFlash, in order to fully utilize the storage space, no partition table is established, but the partition is defined by the developer setting macro in the development process. The master Flash and the backup Flash adopt the same physical address allocation scheme, and the specific partition is as shown in Figure 2 ,

[0051] Figure 2 Among them, the address range 0x0~0x4FFFFF: is used to store the Uboot firmware program, and the size of the Uboot firmware program is generally about 4MB;

[0052] The address range 0x500000~0x50FFFF: is used to store the environment variables of Uboot, and the size of the environment variables is generally several hundred bytes;

[0053] The address range 0x510000~0x5FFFFF: is a reserved space (reserve) for storing the CRC check value and other key data of the ONIE microsystem;

[0054] The address range 0x600000~0xFFFFFF: is used to store the ONIE microsystem, and the size of the ONIE microsystem is generally 8-9MB. The ONIE system is based on the Linux kernel architecture and is used to build an installation environment for the network operating system NOS.

[0055] Step two: Uboot master-slave cooperation and single event effect repair

[0056] As shown in the figure, when the device is powered on, first run the Uboot firmware program selected by the CPLD (programmable logic device controller) master-slave register. The default value of the CPLD master-slave register is the master area (main Flash), so the first start is preferentially started from the main Flash. The specific process is as follows: Figure 3

[0057] Main Flash Uboot startup detection: if the Uboot firmware program in the main Flash can start normally, check whether the version numbers of the Uboot firmware programs in the main Flash and the backup Flash are consistent after starting;

[0058] If the version numbers are consistent, turn off the watchdog and execute the next stage process (load ONIE microsystem);

[0059] If the version numbers are inconsistent, overwrite the Uboot firmware program in the main Flash into the backup Flash to complete the master-slave synchronization operation. After synchronization is completed, turn off the watchdog and execute the next stage process;

[0060] At the same time, during the startup and running of the Uboot in the main Flash, periodically perform CRC check on the Uboot firmware program. If it is detected that the check is not passed due to single event upset (i.e. firmware program data error), immediately trigger the master-slave switching process to copy the Uboot firmware program in the backup Flash into the main Flash to realize firmware repair. If the main Flash is damaged due to single event latch-up and the Uboot firmware program cannot be read, directly start the Uboot firmware program in the backup Flash.

[0061] As shown in the figure, main Flash Uboot startup failure processing: if the Uboot firmware program in the main Flash fails to start, after waiting for 150 seconds, the watchdog register is turned off due to timeout, the CPLD triggers the timeout scheme, selects the backup Flash and restarts the device to try to start the Uboot firmware program from the backup Flash. If the Uboot firmware program in the backup Flash starts successfully, copy the Uboot firmware program in the backup Flash into the main Flash to complete the master-slave switching operation. After copying is completed, compare whether the contents of the Uboot firmware programs in the main Flash and the backup Flash are consistent; Figure 4 If they are consistent, it means that the main Flash repair is completed, the CPLD switches to select the main Flash, and after restarting the device, it starts normally from the main Flash;

[0062]

[0063] ​​If not, it means that the main Flash repair fails, the device will start the Uboot firmware program from the backup Flash, maintain basic operation, and issue a fault alarm signal to the satellite integrated electronic component telemetry component, and start the satellite network node emergency switching.

[0064] Step three: Uboot environment variable master-slave check and repair:

[0065] During the running of Uboot, the environment variable of Uboot is checked to ensure the reliability of the environment variable, and the specific process is as shown in Figure 5

[0066] Main area environment variable check: first read the Uboot environment variable in the main Flash, calculate the check value of the environment variable through the CRC algorithm, and compare the calculated check value with the original saved check value;

[0067] If they are consistent, it means that the environment variable in the main Flash is reliable, and the environment variable is directly applied;

[0068] If they are not consistent, it means that the environment variable in the main Flash is unreliable (may be caused by single event upset to cause data error, or no environment variable saved to the main Flash), at this time, the environment variable in the backup Flash is read and the CRC check of the environment variable in the backup Flash is performed;

[0069] If the CRC check of the environment variable in the backup Flash passes, it means that the environment variable in the backup Flash is reliable, the environment variable in the backup Flash is copied to the main Flash, the repair and synchronization of the environment variable are completed, and then the repaired environment variable is applied;

[0070] If the CRC check of the environment variable in the backup Flash also fails, it means that the environment variable in the backup Flash is also unreliable (or blank area), at this time, the default environment variable is started, the default environment variable is written in the Uboot program, generally realized through the macro definition in the.h file.

[0071] Main and backup environment variable consistency check: when the environment variable in the main Flash is reliable and directly applied, in the subsequent process, the environment variables in the main Flash and the backup Flash are respectively read into two different addresses in the memory, the data in the two addresses is compared directly to judge whether the main and backup environment variables are consistent;

[0072] If there is no difference, it means that the main and backup environment variables are consistent, and no backup operation is needed;

[0073] ​If there is a difference, it means that the environment variable in the backup Flash is outdated or has errors due to single particle flip. The environment variable in the main Flash is backed up to the backup Flash, ensuring that the main and backup environment variables are consistent, and providing a reliable backup for possible subsequent environment variable damage.

[0074] Step four: ONIE system main and backup backup and integrity check repair:

[0075] The ONIE system is used to build an installation environment for a network operating system (NOS). The main and backup backup and integrity check repair process of the ONIE system is as follows:

[0076] ONIE microsystem installation and synchronization: When installing the ONIE system, write the ONIE system file to the specified partition (address range 0x600000~0xFFFFFF) of the main Flash. At the same time, calculate the CRC check value of the current ONIE system by CRC algorithm, and store the check value to the reserved area (address range 0x510000~0x5FFFFF) of the main Flash. Then, synchronize the ONIE system file and the corresponding CRC check value in the main Flash to the corresponding partition in the backup Flash, completing the main and backup backup of the ONIE system.

[0077] ONIE system pre-startup check: Before starting the ONIE system, first read the ONIE system file in the main Flash, calculate its current CRC check value by CRC algorithm, and compare the calculation result with the original CRC check value stored in the reserved area.

[0078] If they are consistent, it means that the ONIE system file in the main Flash is complete and reliable, and the ONIE system can be started normally.

[0079] If they are not consistent, it means that the ONIE system file in the main Flash may be damaged due to single particle flip. At this time, read the ONIE system file in the backup Flash, calculate its CRC check value, and compare it with the original CRC check value stored in the reserved area.

[0080] If the CRC check of the ONIE system file in the backup Flash passes, it means that the ONIE system file in the backup Flash is complete and reliable, and the ONIE system in the backup Flash can be started normally. After starting, the ONIE system file in the backup Flash is copied to the main Flash, completing the repair of the ONIE system in the main Flash.

[0081] If the CRC check of the ONIE system file in the standby Flash also fails, it means that the ONIE system file in the master and standby Flash has been damaged, at this time, the ONIE system fails to start, the device stays in the Uboot mode, and a fault alarm signal is issued to the starboard integrated electronic assembly telemetry component, and the satellite network node emergency switching is started.

[0082] Step five: SSD hard disk reliability guarantee based on RAID1 algorithm and single particle effect repair:

[0083] At least two SSD hard disks are used to construct a storage architecture (soft RAID1) based on the RAID1 algorithm for storing the NOS operating system image, and the specific scheme is as follows:

[0084] As shown in Figure 6 , the RAID1 configuration and metadata setting: since Uboot does not support RAID1 configuration, only two independent SSD hard disks (denoted as SSD0 and SSD1) can be recognized at the UBoot level, SSD0 is the first SSD hard disk, and SSD1 is the second SSD hard disk. In order to ensure that Uboot can recognize and read the data in the SSD hard disk, the metadata version of the SSD hard disk needs to be set to 0.9 format, that is, the metadata is fixedly stored in the tail 128K space of the SSD hard disk. According to the characteristics of the RAID1 algorithm, all files (including NOS operating system files) generated in md0 and all operations on the files are synchronized in SSD0 and SSD1 in real time, realizing the mirror backup of data;

[0085] As shown in Figure 7 , operating system startup check and repair: when Uboot starts and begins to boot the NOS operating system, first read the kernel startup file of the NOS operating system in SSD0, calculate the CRC check value of the file through the CRC algorithm, and compare the calculation result with the syscrc.bin file (pre-stored original CRC check value of the kernel startup file) stored in SSD0;

[0086] If they are consistent, it means that the kernel startup file in SSD0 is complete and reliable, the file is loaded into the memory, and the NOS operating system is started;

[0087] If they are inconsistent, it means that the kernel startup file in SSD0 may be damaged due to single particle flip, at this time, the kernel startup file of the NOS operating system in SSD1 is read, the CRC check value is calculated, and compared with the syscrc.bin file stored in SSD1;

[0088] If the two are consistent, it means that the kernel startup file in SSD1 is complete and reliable, the file is loaded into the memory, the NOS operating system is started, and after starting, the kernel startup file in SSD1 is copied to SSD0, completing the repair of the kernel startup file in SSD0; At the same time, other NOS operating system files in SSD0 that may be damaged by single event upset are scanned and repaired to ensure the consistency of the files in SSD0 and SSD1.

[0089] If the two are inconsistent, it means that the kernel startup file in SSD0 and SSD1 has been damaged (may be caused by a serious single event upset or single event latchup), at which time the NOS operating system fails to start, the device stays in Uboot mode, and a fault alarm signal is issued to the satellite integrated electronic assembly telemetry component, and the satellite network node emergency switching is started.

[0090] The embodiment has the following effects:

[0091] 1. Efficient use of storage resources: The embodiment defines partitions by setting macros in the development process, rather than using a traditional partition table, avoiding the occupation of storage space by the partition table, fully utilizing the limited space of the Flash, improving the utilization rate of storage resources, and reducing the storage cost of the satellite device.

[0092] 2. High reliability of Uboot firmware: The dual-Flash master-slave architecture, combined with master-slave synchronization, master-slave switching, and regular CRC checking mechanism, not only enables quick switching to the backup Flash when the main Flash firmware is damaged, ensuring normal system startup, but also repairs firmware data errors caused by single event upset in space environment in a timely manner, provides a backup solution for Flash damage caused by single event latchup, and greatly improves the reliability of Uboot firmware operation.

[0093] 3. Stable and reliable Uboot environment variables: The dual-CRC checking, automatic repair and synchronization mechanism of the master-slave environment variables ensures the reliability of the environment variables, avoids the impact of single event upset on system startup and configuration due to environment variable errors or loss, and provides protection for system startup in extreme situations by default, further improving the stability of the system.

[0094] 4. Reliable startup of ONIE microsystem: The master-slave backup and pre-startup integrity checking mechanism of the ONIE system can timely detect and repair ONIE system file damage caused by single event upset, ensuring that the ONIE system can be started reliably, providing a stable basic environment for the installation of the NOS operating system, and avoiding the failure of the operating system installation due to ONIE system failure.

[0095] 5. High reliability of SSD hard disk storage: the SSD hard disk mirroring backup scheme based on the RAID1 algorithm realizes real-time synchronous backup of the NOS operating system file, and in combination with the CRC check before starting and the repair mechanism after starting, can effectively deal with the file damage problem caused by single event upset; at the same time, for the damage of the SSD hard disk caused by single event latchup, the hard disk removal, replacement and array reconstruction scheme is provided, ensuring the reliability of the NOS operating system storage and operation.

[0096] 6. Low cost and high reliability: the present application is based on double Flash and at least two SSD hard disks, the hardware cost is relatively low, and at the same time, through perfect master-slave cooperation, verification and repair mechanism, the single event effect in the spaceborne environment is effectively dealt with, realizing the consideration of low cost and high reliability, suitable for spaceborne devices with requirements for cost and reliability.

[0097] 7. Can be used with three-mode redundancy: the scheme can be used with the traditional three-mode redundancy scheme, and can also be used as a reliable backup guarantee scheme after the failure of a single chip of three-mode redundancy.

[0098] The basic principles of the present disclosure are described above in combination with specific embodiments, but it should be pointed out that the advantages, advantages, effects and the like mentioned in the present disclosure are only examples and not limitations, and these advantages, advantages, effects and the like cannot be considered as the necessary possession of each embodiment of the present disclosure. In addition, the specific details of the above disclosure are only for the purpose of example and for the purpose of understanding, and are not limited to the above specific details, and the present disclosure is not limited to the above specific details.

[0099] In the present disclosure, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between the entities or operations. The block diagram of the device, apparatus, equipment, system involved in the present disclosure is only an illustrative example and is not intended to require or imply the connection, arrangement, configuration shown in the block diagram. As those skilled in the art will recognize, these devices, apparatuses, equipment, systems can be connected, arranged, configured in any manner. Words such as "include", "contain", "have" and the like are open-ended words, which mean "including but not limited to", and can be used interchangeably. The words "or" and "and" used herein mean the word "and / or", and can be used interchangeably unless the context clearly indicates otherwise. The word "such as" used herein means the phrase "such as but not limited to", and can be used interchangeably.

[0100] Also, as used in the description herein and throughout the claims that follow, the meaning of "or" includes "and / or" unless the context clearly dictates otherwise. For example, when used in the examination of "at least one of A or / and B" the phrase "at least one of A or B" means A or B or both. As used in the examination of "between one and three of A, B, and C," the phrase means A or B or C, or any combination thereof.

[0101] It is also important to note that the systems and methods of the disclosure can be embodied in a variety of forms depending on the particular requirements of the applications. Some embodiments can be implemented in software, while other embodiments can be implemented in hardware or a combination of software and hardware. As used herein the term "software" includes but is not limited to one or more computer program(s) or other computer readable instructions that can be stored or carried on a computer readable medium, such as a floppy disk, a flexible disk, a hard disk, a magnetic tape, a magnetic disk, an optical disk, a CD-ROM, RAM, ROM, PROM, EPROM, a flash memory, a solid state drive, or other memory chip or cartridge, or the like.

[0102] Various changes, modifications and alterations to the techniques described herein can be made without departing from the teachings of the attached claims. Moreover, the scope of the claims should not be limited to the particular aspects described in the above description and drawings. Rather, the scope of the claims should be understood to include all aspects and equivalents thereof that are within the scope of the claims. The disclosure is not intended to be limited to the aspects specifically identified hereinabove. Rather, the scope of the disclosure includes all aspects and equivalents thereof that are within the scope of the claims.

[0103] The above description of disclosed aspects is intended to be illustrative, and not restrictive. Many other aspects can be apparent to those of skill in the art upon reviewing the above description. The scope of the disclosure should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. The claims can be amended after filing to add dependent claims.

[0104] The above description has been given by way of example. Further, this description does not aim to limit embodiments of the disclosure to forms disclosed herein. Although a number of example aspects and embodiments have been discussed above, those of skill in the art will recognize certain modifications, permutations, additions, and sub-combinations thereof.

Claims

1. A dual-Flash-based spaceborne network operating system guarantee method, characterized in that, The main Flash memory and the backup Flash memory are used to store a boot program Uboot and a micro system ONIE, and at least two SSD hard disks are used to construct an image array to store a network operating system NOS; The guarantee method comprises double-Flash partition planning, Uboot master-slave cooperation and single particle effect repair, Uboot environment variable master-slave checking and repair, ONIE system master-slave backup and integrity checking and repair, and SSD hard disk reliability guarantee and single particle effect repair; The Uboot environment variable master-slave checking and repair comprises: The Uboot environment variable is checked by the master and the backup, when the environment variable checking of the main Flash memory fails, the environment variable in the backup Flash memory is used for repair and synchronization, if both of them fail, the default environment variable written in the Uboot program is enabled, The Uboot environment variable master-slave checking and repair specifically comprises: firstly, the Uboot environment variable in the main Flash is read, the checking value of the environment variable is calculated through a CRC algorithm, and the calculated checking value is compared with the originally saved checking value; If the two are consistent, it is indicated that the environment variable in the main Flash is reliable, and the environment variable is directly applied; If the two are inconsistent, it is indicated that the environment variable in the main Flash is unreliable, at this time, the environment variable in the backup Flash is read, and the environment variable in the backup Flash is checked through the CRC algorithm; If the CRC checking of the environment variable in the backup Flash passes, it is indicated that the environment variable in the backup Flash is reliable, the environment variable in the backup Flash is copied to the main Flash, the repair and synchronization of the environment variable are completed, and then the repaired environment variable is applied; The Uboot master-slave cooperation and single particle effect repair comprises: when the device is powered on, the master-slave register of a programmable logic device CPLD is used to control the Uboot to be started from the main Flash memory preferentially, and the starting process is monitored through a watchdog mechanism. The Uboot master-slave cooperation and single particle effect repair comprises: If the Uboot firmware program in the main Flash memory can be normally started, after starting, whether the version numbers of the Uboot firmware programs in the main Flash memory and the backup Flash memory are consistent is checked; If the version numbers are consistent, the watchdog is closed, and the ONIE micro system is loaded; If the version numbers are inconsistent, the Uboot firmware program in the main Flash memory is overwritten into the backup Flash memory, the master-slave synchronization operation is completed, and after the synchronization is completed, the watchdog is closed.

2. The dual-Flash based space-borne network operating system assurance method according to claim 1, wherein, The double-Flash partition planning comprises: The main Flash memory and the backup Flash memory adopt the same physical address allocation scheme for partitioning, the partitioning is defined by setting a macro, and the partitioning includes a first address range for storing a Uboot firmware program, a second address range for storing a Uboot environment variable, a third address range used as a reserved area, and a fourth address range for storing an ONIE microsystem, and the third address range stores data including check data.

3. The dual-Flash based space-borne network operating system assurance method of claim 1, wherein, The Uboot main-backup cooperation and single particle effect repair further include: If the main Flash memory fails to start, a programmable logic device CPLD is triggered by a watchdog timeout to switch to starting from the backup Flash memory, and a main-backup Flash memory switching and repair process is performed. During Uboot running, the Uboot firmware program in the main-backup Flash memory is periodically checked, if the check fails due to single particle flip, the main-backup Flash memory switching repair process is triggered, and if the main Flash memory is damaged due to single particle latch-up, the backup Flash memory is directly switched to start.

4. The dual-Flash based space-borne network operating system assurance method of claim 1, wherein, If the main Flash memory fails to start, a programmable logic device CPLD is triggered by a watchdog timeout to switch to starting from the backup Flash memory, and a main-backup Flash memory switching and repair process is performed, including: If the Uboot firmware program in the main Flash memory fails to start, after waiting for a set time, the watchdog register is closed due to timeout, the programmable logic device CPLD triggers a timeout scheme, selects the backup Flash memory and restarts the device to attempt to start the Uboot firmware program from the backup Flash memory, if the Uboot firmware program in the backup Flash memory starts successfully, the Uboot firmware program in the backup Flash memory is copied to the main Flash memory to complete the main-backup switching operation, after copying is completed, the contents of the Uboot firmware program in the main Flash memory and the backup Flash memory are compared to determine whether they are consistent; If they are consistent, the programmable logic device CPLD switches to select the main Flash memory, and after restarting the device, the main Flash memory is normally started; If they are inconsistent, the device starts the Uboot firmware program from the backup Flash memory, maintains running, and issues a fault alarm signal to a satellite integrated electronic assembly telemetry component, and starts satellite network node emergency switching.

5. The dual-Flash based space-borne network operating system assurance method of claim 1, wherein, The main-backup dual check on the Uboot environment variable includes main-backup environment variable consistency checking, when the environment variable in the main Flash memory is directly applied, the environment variables in the main Flash memory and the backup Flash memory are respectively read into two different addresses in the memory, the data in the two addresses are directly compared to determine whether the main-backup environment variables are consistent; If they are inconsistent, the environment variable in the main Flash memory is backed up to the backup Flash memory.

6. The dual-Flash based space-borne network operating system assurance method of claim 1, wherein, The ONIE system main-backup backup and integrity check repair includes: Before starting the ONIE system, the integrity of the ONIE system file in the main Flash memory is checked, if the check fails, the ONIE system file in the backup Flash memory is used to start and repair the main Flash memory, if the ONIE system file in the main and backup Flash memories are both damaged, the starting fails and an alarm is given.

7. The dual-Flash based space-borne network operating system assurance method of claim 1, wherein, The reliability guarantee and single particle effect repair of the SSD hard disk include: When booting the NOS operating system, the integrity of the kernel startup file in the first SSD hard disk is first checked, if the check fails, the second SSD hard disk is switched to start, and the damaged file is repaired by using the mirror array, if the kernel startup files in the two SSD hard disks are both damaged, the starting fails and an alarm is given.

8. The dual-Flash based spaceborne network operating system assurance method of claim 7, wherein, The reliability guarantee and single particle effect repair of the SSD hard disk include RAID1 configuration and metadata setting, the metadata is fixedly stored in the tail space of the SSD hard disk; the first SSD hard disk and the second SSD hard disk are combined into a RAID1 disk array through the RAID1 algorithm.

Images