Chip capable of performing three-mode protection

Abstract

The invention provides a chip capable of performing three-mode protection. The chip comprises a program storage area, a first program verification and software module, a second program verification and software module and a comparison module. Wherein the program storage area is used for storing an injection program and a first checksum, after the injection program is divided into N program blocks on the ground, the injection program and the first checksum obtained by checking the program blocks are uploaded to the program storage area twice, and the injection program and the first checksum are respectively recorded as a main program and a backup program; the first program checksum software module is used for checking the N main program blocks to obtain a second checksum of all the main program blocks, and the second program checksum software module is used for checking the corresponding backup program blocks to obtain a corresponding third checksum after each main program block is checked to obtain a second checksum of all the main program blocks; the comparison module is used for comparing the first checksum, the second checksum and the third checksum of the corresponding program blocks; if the first checksum, the second checksum and the third checksum are consistent, operation is not carried out; and if the three are inconsistent, updating the program or the checksum, and re-checking the program or the checksum.

Description

Technical Field

[0001] The present invention relates to the field of aerospace technology, and in particular to a verification-based three-mode storage method for program blocks.

[0002] This application is a divisional application based on the parent case "A verification-based three-mode storage method for program blocks" (application number: 2021115581820, application date: December 20, 2021). Background Art

[0003] The radiation effect of the space environment is one of the main causes of spacecraft anomalies and failures. The universe is filled with various forms of matter, such as plasma and charged particles of various energies, which may have harmful effects on spacecraft. The single particle effect is the most typical one. The single particle effect refers to the radiation effect caused by a single high-energy proton or heavy ion incident on an electronic component. It can be divided into: single particle flip, lock, burnout, gate breakdown, etc. according to different mechanisms. Usually, the single particle effect can be improved by strengthening the chip itself against radiation and strengthening the aircraft itself against radiation.

[0004] Common single-particle protection methods include EDAC, triple-mode redundancy, and timed refresh. Among them, the implementation principle of EDAC is to add some check codes to the transmitted data source code, so that the data source code and the check code establish a relationship according to certain rules. When an error occurs in the legal data encoding, the relationship between the data source code and the check code is destroyed, forming an illegal code, and the receiving end can detect the error by detecting the legality of the code until the error is corrected. Generally, aerospace-grade processors have built-in EDAC functions. If they do not have it, additional protection measures need to be configured.

[0005] Triple-mode redundancy refers to the storage and voting of three copies of the flags that have a significant impact on the program operation and the parameters or codes that play a key role in the operation structure. After the three-mode voting, if a single particle is overturned, the refresh program is started and the overturned bit is corrected using the three-mode voting results. This method consumes a lot of resources, and the code redundancy reaches more than 2 / 3.

[0006] The above two methods are currently commonly used means to deal with single-particle effects on orbit. Depending on the type of chip and the resource allocation, a reasonable method can be selected for single-particle protection.

[0007] In actual use, as satellite functions become more and more powerful, the chip resource utilization rate has almost reached its limit. Limited by the limited resources of aerospace-grade chips, in order to achieve the complex functional performance of satellites, considering the satellite power consumption, heat consumption, and cost, it is often impossible to achieve full three-mode redundancy of on-orbit programs. Generally, when designing programs, priority is given to ensuring the three-mode redundancy of data in the program running area and key parameter storage area, while the code storage area, program loading and other links will be considered as secondary priorities. Therefore, when the aerospace-grade chip itself does not have the EDAC function, for large programs running in the processor, program data and important data stored in the memory, etc., a new, more effective, and less resource-intensive method is needed to replace the traditional method that requires a large amount of redundant resources to achieve EDAC or three-mode redundancy. Summary of the invention

[0008] In view of some or all of the problems in the prior art, the present invention provides a program block three-mode storage method based on verification, comprising:

[0009] Divide the program to be injected into N program blocks, and verify each program block to obtain a first checksum;

[0010] Injecting two programs to be injected and a first checksum into the program storage area, wherein the two injected programs to be injected are recorded as a main program and a backup program respectively;

[0011] Divide the main program into N program blocks, and during program execution, verify each program block to obtain a second checksum;

[0012] Dividing the backup program into N program blocks, and verifying each program block to obtain a third checksum; and

[0013] Compare the first checksum, the second checksum, and the third checksum:

[0014] If the three are consistent, no operation is performed; and

[0015] If the three are inconsistent, update the program or checksum and recheck.

[0016] Further, the first checksum and / or the second checksum and / or the third checksum are obtained by an exclusive-OR check.

[0017] Furthermore, the XOR check is performed every 32 bits, and the first checksum and / or the second checksum and / or the third checksum are an array of N*32 bits.

[0018] Furthermore, the program block three-mode storage method includes:

[0019] During program execution, a checksum comparison is performed each time a 32-bit checksum is generated.

[0020] Furthermore, the main program and the backup program are verified using independent verification modules respectively.

[0021] Further, the updating of the program or checksum includes:

[0022] If the first checksum is equal to the second checksum but not equal to the third checksum, comparing the main program and the backup program bit by bit, and correcting the backup program according to the main program;

[0023] If the first checksum is equal to the third checksum but not equal to the second checksum, comparing the main program and the backup program bit by bit, and correcting the main program according to the backup program;

[0024] If the second checksum is equal to the third checksum but not equal to the first checksum, correcting the first checksum according to the second checksum or the third checksum; and

[0025] If the first checksum, the second checksum and the third checksum are all different, reload all the software and perform the check again.

[0026] Furthermore, the updating of the program or checksum also includes:

[0027] If no differences are found when comparing the main program and the backup program bit by bit, reload the verification module and perform verification again.

[0028] Another aspect of the present invention provides a satellite that adopts the verification-based three-mode storage method of program blocks as described above.

[0029] The program block three-mode storage method based on verification provided by the present invention divides the program into program blocks, verifies each program block, compares the checksum values ​​of the main program, the backup program and the pre-calculated on the ground, and then determines whether a single particle effect occurs. At the same time, the method can also update the erroneous program in real time to ensure the stable operation of the on-orbit software, and the overall method is simple and effective. Since the program is divided into small program blocks, the verification process and the subsequent checksum comparison operation account for a very small proportion of redundant resources, usually less than one thousandth. When the chip storage resources are insufficient, the method effectively utilizes limited resources to complete the three-mode protection of the code storage area, program loading, etc., and can be applied to aerospace chips without EDAC and with tight resources, meeting the single particle protection design requirements for large-block program storage / data storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] To further illustrate the above and other advantages and features of various embodiments of the present invention, a more specific description of various embodiments of the present invention will be presented with reference to the accompanying drawings. It will be understood that these drawings only depict typical embodiments of the present invention and are therefore not to be considered as limiting the scope thereof. In the accompanying drawings, for clarity, identical or corresponding parts will be represented by identical or similar reference numerals.

[0031] Figure 1 A flowchart of a verification-based three-mode storage method for program blocks according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0032] In the following description, the present invention is described with reference to various embodiments. However, those skilled in the art will recognize that various embodiments can be implemented without one or more specific details or with other replacement and / or additional methods, materials or components. In other cases, well-known structures, materials or operations are not shown or described in detail to avoid blurring the inventive point of the present invention. Similarly, for the purpose of explanation, specific quantities, materials and configurations are set forth to provide a comprehensive understanding of embodiments of the present invention. However, the present invention is not limited to these specific details. In addition, it should be understood that the various embodiments shown in the drawings are illustrative representations and are not necessarily drawn in correct proportions.

[0033] In this specification, reference to "one embodiment" or "the embodiment" means that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present invention. The phrase "in one embodiment" appearing in various places in this specification does not necessarily all refer to the same embodiment.

[0034] It should be noted that the embodiments of the present invention describe the steps in a specific order, but this is only for the purpose of illustrating the specific embodiment, rather than limiting the order of the steps. On the contrary, in different embodiments of the present invention, the order of the steps can be adjusted according to actual needs.

[0035] Since triple-mode redundancy consumes a lot of resources, it is usually difficult to perform full triple-mode redundancy on large programs running in the processor, program data stored in the memory, and important data in practical applications. This makes it difficult to effectively implement single-particle protection when the aerospace-grade chip itself does not have the EDAC function. Based on this, the present invention proposes a program block triple-mode storage method based on verification, which provides triple-mode redundancy, verification and refresh of codes for a program storage area that can only store two copies of code and has no EDAC function. It divides the program into N program blocks, calculates the checksum of each program block and the backup program, and then compares it with the checksum pre-calculated on the ground: if the three are consistent, no operation; and if the three are inconsistent, the update of the error module or checksum is achieved by taking two out of three. The scheme of the present invention is further described below in conjunction with the accompanying drawings of the embodiments.

[0036] Figure 1 FIG. 1 is a flow chart showing a method for storing program blocks in three modes based on verification according to an embodiment of the present invention. Figure 1 As shown, a program block three-mode storage method based on verification includes:

[0037] First, in step 101, program injection. Before program injection, the program to be injected is first divided into N program blocks, and each program block is checked to obtain a first checksum, and then the first checksum is injected into the program storage area together with the stored program. In an embodiment of the present invention, the program to be injected and the first checksum need to be injected twice into the program storage area, and the two injected programs to be injected are respectively recorded as the main program and the backup program; in an embodiment of the present invention, the program block is XOR-checked at every 32 bits;

[0038] Next, in step 102, program verification. The main program is divided into N program blocks, and during the program running, each program block is verified by the first verification module to obtain a second checksum. At the same time, the backup program is divided into N program blocks, and each program block is verified by the second verification module to obtain a third checksum. In one embodiment of the present invention, in order to avoid the checksum being wrong at the same time due to a single particle overturning, affecting the subsequent results, the code content of the first verification module and the second verification module is the same, but it should occupy two independent spaces in the program to implement, which can also be understood as being completed by two independent functions respectively; in one embodiment of the present invention, each program block of the main program and the backup program is XOR-checked at every 32bit; and

[0039] Finally, in step 103, the checksum is compared. The first checksum, the second checksum and the third checksum are compared, and subsequent operations are performed according to the comparison results. In one embodiment of the present invention, if the first checksum, the second checksum and the third checksum are the same, it means that the software is running normally and no single particle event has occurred. At this time, no operation is performed; if the first checksum, the second checksum and the third checksum are inconsistent, it indicates that a single particle event may occur, and the program or checksum needs to be updated according to the specific results. Specifically:

[0040] If the first checksum is equal to the second checksum but not equal to the third checksum, it indicates that the checksum of the backup program may be overturned by a single particle. At this time, the main program and the backup program are compared bit by bit, and the backup program is corrected according to the main program. If no difference is found when the main program and the backup program are compared bit by bit, the verification module is reloaded and the verification is performed again; if the first checksum is equal to the third checksum but not equal to the second checksum, it indicates that the checksum of the main program may be overturned by a single particle. At this time, the main program and the backup program are compared bit by bit, and the main program is corrected according to the backup program. If no difference is found when the main program and the backup program are compared bit by bit, the verification module is reloaded and the verification is performed again;

[0041] If the second checksum is equal to the third checksum but not equal to the first checksum, it indicates that the injected first checksum may be upset by a single particle, and the first checksum is corrected according to the second checksum or the third checksum; and

[0042] If the first checksum, the second checksum and the third checksum are all different, it indicates that the program is wrong. At this time, reload all the software and check again.

[0043] In one embodiment of the present invention, during the stable operation of the satellite software, the checksum comparison is performed once after the checksum of each program block is completed, rather than after all program blocks of the main program and the backup program are checked. Specifically, it includes the following steps:

[0044] First, the program to be injected is divided into program block 1, program block 2, program block 3, ..., program block N on the ground, and then each program block is XOR-checked every 32 bits to obtain a set of N*32-bit checksum result arrays C = {c1, c2, c3c4, c5, ... cN}, and the checksum result array C will be injected into the program storage area in the satellite chip together with the program to be injected; next, the program to be injected and the checksum result array C are injected twice into the program storage area in the satellite chip;

[0045] Next, the first program in the program storage area is used as the main program and divided into main program block 1, main program block 2, main program block 3, ..., main program block N. The second program in the program storage area is used as the backup program and divided into backup program block 1, backup program block 2, backup program block 3, ..., backup program block N. In the process of program running, the first program checksum software module is called to perform an XOR check on each main program block of the main program in the program storage area every 32 bits in real time to generate a set of N*32-bit checksum result arrays A={a1, a2, a3, a4, a5, ..., aN}. In the process of stable operation of the satellite software, each time a 32-bit checksum ai (i=1, 2, ..., N) is generated, the second program checksum software module is called to perform an XOR check on the corresponding backup program block of the backup program in the program storage area every 32 bits to obtain a corresponding 32-bit checksum result bi. Then, the values ​​of ai, bi and the corresponding ci are compared to see if the three are the same:

[0046] If ai=bi=ci, it means that the software is running normally and no single particle event has occurred. No operation is performed at this time;

[0047] If ai=ci≠bi, it indicates that the checksum of the backup program in the program storage area may be upset by a single particle. At this time, the main program and the backup program are compared bit by bit, and the backup program is corrected according to the main program. If no difference is found during the bit-by-bit comparison, the first and / or second program checksum software module is reloaded and checked again after loading;

[0048] If bi=ci≠ai, it indicates that the main program checksum in the program storage area may be overturned by a single particle. At this time, the main program and the backup program are compared bit by bit, and the main program is corrected according to the backup program. If no difference is found during the bit-by-bit comparison, the first and / or second program checksum software module is reloaded and checked again after loading;

[0049] If ai=bi≠ci, it indicates that the injected checksum data may be overturned by a single particle. In this case, the checksum value of ai or bi is rewritten into the storage space of ci, and subsequent checks are continued; and

[0050] If ai, bi, and ci are all different, it indicates that the program has run into an error. In this case, reload all the software, and then restart the program and verify it.

[0051] The program block three-mode storage method based on verification provided by the present invention divides the program into program blocks, verifies each program block, compares the checksum values ​​of the main program, the backup program and the pre-calculated on the ground, and then determines whether a single particle effect occurs. At the same time, the method can also update the erroneous program in real time to ensure the stable operation of the on-orbit software, and the overall method is simple and effective. Since the program is divided into small program blocks, the verification process and the subsequent checksum comparison operation account for a very small proportion of redundant resources, usually less than one thousandth. When the chip storage resources are insufficient, the method effectively utilizes limited resources to complete the three-mode protection of the code storage area, program loading, etc., and can be applied to aerospace chips without EDAC and with tight resources, meeting the single particle protection design requirements for large-block program storage / data storage.

[0052] Although various embodiments of the present invention are described above, it should be understood that they are presented as examples only and not as limitations. It is obvious to those skilled in the relevant art that various combinations, modifications and changes can be made thereto without departing from the spirit and scope of the present invention. Therefore, the breadth and scope of the present invention disclosed herein should not be limited by the exemplary embodiments disclosed above, but should only be defined according to the attached claims and their equivalents.

Claims

1. A chip capable of performing triple-mode protection, characterized in that: include: A program storage area, which is configured to store an injection program and a first checksum, wherein after the injection program is divided into N program blocks on the ground, it is uploaded to the program storage area twice together with the first checksum obtained by checking each program block, and the twice uploaded programs are respectively recorded as a main program and a backup program; A first program checksum software module is configured to check the N main program blocks one by one to obtain a second checksum of each main program block; A second program checksum software module is configured to check the corresponding backup program block after completing the check of each main program block to obtain a third checksum of the corresponding backup program block; as well as A comparison module configured to compare a first checksum, a second checksum, and a third checksum of corresponding program blocks, wherein: If the three are consistent, no operation will be performed; as well as If the three are inconsistent, update the program or checksum and recheck.

2. The chip according to claim 1, characterized in that: The first checksum, the second checksum, and the third checksum are obtained through XOR checking.

3. The chip according to claim 2, characterized in that: The XOR check is performed every 32 bits, and the first checksum, the second checksum, and the third checksum are arrays of N*32 bits.

4. The chip according to claim 1, characterized in that: The first program checksum software module and the second program checksum software module have the same code, but they occupy independent spaces respectively.

5. The chip according to claim 1, characterized in that: The updating of the program or checksum includes: If the first checksum is equal to the second checksum but not equal to the third checksum, comparing the main program and the backup program bit by bit, and correcting the backup program according to the main program; If the first checksum is equal to the third checksum but not equal to the second checksum, comparing the main program and the backup program bit by bit, and correcting the main program according to the backup program; If the second checksum is equal to the third checksum but not equal to the first checksum, correcting the first checksum according to the second checksum or the third checksum; and If the first checksum, the second checksum and the third checksum are all different, then all software is reloaded, and then re-run and re-checked.

6. The chip according to claim 5, characterized in that: The updating of the program or checksum also includes: If no difference is found when comparing the main program and the backup program bit by bit, reload the verification module and perform verification again after loading.

Images